Lately, we’ve been hot on top considerations, lists, and high-level descriptions of some of the major business-level issues in cloud. Today, we want to continue that trend, but focus on the all important and pivotal moment in your relationship with your new cloud provider: The infrastructure migration. Here are some considerations you must be making mapped to the different phases of that process.
Project management: The only way that a migration ever works successfully comes down to coordination between the teams (both on a technical and a business level) at the source and the teams at the target. The success of a a migration is based in the minutia: details, scheduling, etc. You should plan for as much validation time at the new site as possible because you will want to put your code there, run application tests against it and generally make sure it works.
The new environment: Its almost never an apples to apples transition from your old infrastructure to the new. Typically you will be going from something that was built up over a long period of time, so it will contain older elements and different architectures. When you move to a new site, you will often be changing, modernizing, upgrading the components. This will create a topology change in how your application is set up. You will want to do as thorough as possible an assessment of the source site and work with engineers at the target site to ensure that the environment built there is going to meet of exceed the performance requirements of your business needs.
Data transfer: If there’s a large amount of data to transfer, you need to properly plan for this and make sure you have the bandwidth at both sites to ship it over the internet or a tunnel. Or you have to come up with some way of physically delivering the data and establishing a sync back to the original site. All of this requires detailed coordination between the person doing the moving, the target they are moving to , and some elements of the source they’re moving from.
The cut over: Once you get the data replicated, the environment verified at the new provider, the cut over itself is a time of potential crisis. You need to identify how large of a window you have to cut over. This will be determined by data change rate, replicating form the other side. Part of the consideration here is around minimizing loss of revenue, but this must be balanced with the thoroughness and correctness of the actual cut over. If you try to do it too quickly, you may end up in a situation where you may not have all your data fully established in your new environment. There has to be a period where you freeze rights at the old site, let everything sync up, accomplish the front end cut over. its a trade-off between correctness and being up-to-date and minimal impact on time that the application is available.
Validation of the new environment: You have to make sure there’s ample time to stand up the new environment, install your code base on it, put whatever data you have there, and then run validation testing. Examples include load testing, capture your logs in your existing environment and run a load emulator to simulate your real traffic to see if the new environment can support similar traffic.
If you’ve been diligent in your planning, once you have tested your new environment and migrated your data, you should be live and ready to go. Part of this process, and a key component of the success of this process, will come down to the cloud provider you choose. Their technical team, as well as their business team, will play a major part in making the migration a success. On the other side, your teams need to be as transparent and responsive as possible. Its a coordinated effort, and needs to be viewed in the light of partnership, not simply plug and play.
By Jake Gardner