Has this ever happened to your organization? You have just gone through a seven-hour cloud migration, something goes wrong and the IT team has to stop the process and roll the project back. Later, you relate the experience to an engineer outside the team, and the person responds in a confused manner. “That should have been easy. It was just a lift and shift.”
Of all the cloud migration options, the lift-and-shift approach is probably the least intensive and least risky to pull off. You pick up bundles of small, less critical, on-premises apps, and move them to the cloud. This means you can capture the cloud’s benefits without having to painstakingly rearchitect existing apps or integrate new ones into your organizational processes.
Lift and shift is efficient. It is straightforward. But that does not mean it is easy.
There are complexities hidden under the surface, which organizations may not fully understand. Any one of these wild cards can trip up a project and force team members to start over. Things go wrong, deadlines are missed, costs rise and outside stakeholders unfamiliar with the process begin hurling questions at the project owners. Why is this taking so long? Why did you not catch these issues in QA? Why am I seeing POs to vendors? Why is this so hard?
Lift-and-shift projects are harder than they look, but they can be successfully managed if they are approached the right way. Organizations can pull off these so-called “rehosting” projects efficiently, perhaps even seamlessly, if they know where the problems can come from, and take steps to keep them from getting in the way.
Here are some common lift-and-shift missteps and some tips for avoiding trouble.
Misstep #1: IP address changes can cause ripple effects
Changing an IP address is a small thing, right? Actually, this process can wreak havoc. When you move to the cloud, most likely you will get new IP and MAC addresses. This gets complicated when vendors tie licenses to a specific system profile. To keep the whole application from breaking, you will want to check the status of support contracts and update any lapsed licenses. You will also need to make sure that all connected applications are leveraging DNS and not hard-coded IPs for communication. Application configurations based on hard-coded IPs will need to be updated when the app is migrated.
Misstep #2: You did not account for application dependencies
Very few apps these days operate independent of other systems. To start with, your two-tier application consists of an application server and a database. Is the application server configured to pull data from any other internal systems or third-party vendors? Does the database have DB links to other internal systems? If you do not review the spider of dependencies before migrating an application, a web of issues can unravel as testing continues.
Misstep #3: Did you allow for an outage window?
Moving an app is not like sending an email. It takes time to get from place to place. You will need to set aside an outage window to allow enough time to accomplish a series of maneuvers: migrating the technical server, reconfiguring the application and doing business testing/signoff. You will also want to build in time to roll back systems in the event the migration is unsuccessful. Yes, this means always having a rollback plan ready for each migration.
Misstep #4: Features were not tested in all environments
The standard mitigation approach is to migrate application environments starting with the lowest environment levels, and then make your way up to Production. This allows you to catch any issues and have an expected timeline for the Production migration prior to the migration event. But what if your different environments – Development, Quality Control and Production – are built on their own independent server stacks? All the features may not have been fully tested. You need to work with the application team to develop a prescribed plan to have testing across each environment, so you can work through problems as they come up.
Misstep #5: If you need vendor help, lock it in
If you do encounter a problem, you are going to want to correct it right away. But that may not be possible if you need vendor support and the vendor is not available. If your SLA stipulates that the vendor will call back within, say, four hours, your migration will have to wait. It is best to anticipate potential issues and reach out to vendors ahead, to time to make sure they will offer the support you need and will be around to walk you through a solution.
Misstep #6: Do not sneak in any last-minute changes
Doing a domain change while moving the server may seem like a great idea – kind of like making two improvements at once. This is actually a bad idea. When you change components midstream, you no longer have a steady point to look back on, to make sure the app works the same way. It can confuse the system and force you to roll back much farther than you would have during a normal process.
Misstep #7: Did the application even work before the migration?
This may seem obvious. But if a cloud service does not work correctly after a lift and shift is done, find out if it was actually working before the migration. Problems will not magically fix themselves on the app’s journey to the cloud. Setting proper expectations about app performance before migrations can eliminate finger pointing afterward.
Misstep #8: Check the network ahead of time
Networking controls in the cloud are more restrictive than comparable controls on premises. In the cloud, the firewall policy has to be programmed to determine what connections the networking controls can communicate on. Leveraging a tool to understand what ports and protocols are being used between servers in an application stack will help prevent most migration bridge network troubleshooting issues. Doing a networking analysis ahead of time often reveals dependencies that would cause a required rollback if they had not been previously identified.
Misstep #9: Commit to the cause
To make migrations successful, organizations need to have buy-in not only from IT but also from the business stakeholders themselves. For the first few weeks of an initiative you will probably have everyone’s full attention. Then, as the date approaches, both IT and business units tend to start shifting to other priorities, assuming that all the facets of the migration process are in place. This leads to migrations where critical resources are “unavailable” during the process. Organizations need to keep the pressure on, to make sure that everyone is focused, and the right resources are being allocated.
Conclusion
Bottom line: Migration projects may be complicated, but they can be handled – with the right focus and preparation. Organizations have to commit to the process. They have to identify what can go wrong, head off problems before they appear and then follow through on their plans.
After all, it is not just a lift and shift. It is a vitally important move for the success of your business.
