There are many reasons you might be thinking about moving your Rails app to Engine Yard. Perhaps you grew beyond the capacity of what that service can offer? Perhaps the current service abandoned Rails as a supported part of their service? Perhaps you realized managing hardware yourself is taking time away from building a better application. Whatever the reason, you’ve reached the point where a move to Engine Yard is the right decision, and we’re here to help.
With various reasons for moving your application to Engine Yard, we thought we’d outline the top five things you need to be aware of during a migration. And remember, our support and onboarding teams are there to help at every step of the migration.
Make a Migration Plan
A migration plan is your playbook for what needs to be done at each step of the migration process. It is an essential part of a successful migration. Similar to building an application, a plan is necessary if you want to stay organised.
Fortunately, we have a template for migration plans. This is a great listing of all the common steps that are necessary to move your application from one hosted service to Engine Yard. It should also help to to avoid some of the common issues.
Get started early and work with your devops team nice and early to ensure everything is taken into account before taking action. Once the plan has been assembled and your Engine Yard support person has reviewed it, you can move forward with confidence.
It’s All About That Database
One of the common first steps is to deploy a duplicate of your current production application to your new Engine Yard setup. We support many database options, including MySQL, PostgreSQL, and Riak, and practicaly anything else you might be running.
You will need to dump your existing database using whatever method is appropriate. This will vary depending on the database you are using, the size of your data, and the service you are migrating from, etc. Once you have the dump, check out our guide to restoring or loading databases. As part of our migration service, our support DBAs are standing by to assist in any way.
With a database in place we can move to the next step: making sure everything is right, looks good, and is properly functional.
Staging, Staging, Staging
It’s always a good idea to deploy to staging before production. This is especially true when doing a migration from one platform provider to another.
On staging, everything will look and behave just like production. It just won’t be public yet. This gives us the opportunity to poke and prod the application to ensure everything is working as it should be. We can also load test the Engine Yard setup to reassure ourselves that performance is what it should be.
After this we turn our attention to keeping things running in parallel.
Continue Running Your App on the Old Service
So far, we have left the old service up and running. This is necessary until both you and the Engine Yard support team feel confident the new application environment is ready. Since it’s slightly more complicated than flipping a switch, we recommend leaving both new and old services running simultaneously until the migration is complete.
We understand this is not always possible, however. If your timeline is tight, our support and onboarding teams will be on hand to ensure everything goes smoothly.
Now we move on to the final cutover.
The Final Cutover
When we’ve reached the point of the final cutover, all the checkboxes should be ticked on your migration plan and all testing should have been completed to both your satisfaction and to the satisfaction of your Engine Yard support person. The next step is putting up a maintenance page on your current production application. This is necessary, as DNS changes take time to resolve.
Once DNS chages propagate, live traffic will begin to flow, and you can remove the maintenance page from the old environment. You can shut down the old service once and for all. At this point, the migration is complete and your app is running on Engine Yard.