Hybrid IT migrations, what they're like in real life.Blog
The key to successful hybrid IT migrations: planning, planning, planning
So, you’re going down the hybrid IT path. You’ve got your workload placement strategy sorted out, with due regard to governance, risk, compliance, performance, and cost. Now you’re ready to begin the migration process. The first step is to plan it down to every last imaginable detail.
For example, we recently migrated the primary production platform of a major European automotive manufacturer. This was a massive implementation of 70 SAP systems that all had to be migrated in an 8-hour window.
It took 3 months to plan, and we thought through everything. Who are the go/no-go decision makers? What are the decision criteria? Who should have their mobile number? Should it be on speed dial? And if they’re engaged, who do you phone next?
We had a project conference call bridge that was open 24/7 and we even had contingency plans if someone fell asleep on the call. It didn’t happen, and I’m happy to say the migration went without a hitch. But that was down to good planning.
Cutting over to cloud can be a nail-biting moment
Migrations usually take place in a finite window, typically midnight to 6.00am, because they involve shutting down the business’s entire production system. Stopping a core business process is a full-on change management exercise and it’s really important that it’s extremely carefully planned.
It will usually involve a number of key parties: the business owner of the application, the system administrator in the client’s IT department, the application vendor, the new provider, and the telco providing the connectivity. All parties have to execute the change management plan in a certain sequence.
Before the migration, the new environment will have been set up to within an inch of production and tested thoroughly. The aim is to do as much as possible in advance.
Then at midnight, we stop production. Shut down the database and application servers. Migrate the last pieces of data from the old production platform to a staging platform. And migrate the data across to the new environment.
Then, for the first time, we spin up the application with real data in the new environment, and all the parties begin their testing. The database administrator checks for data integrity, and the client runs user-acceptances tests, covering individual transactions and batch processes, and we observe performance against predefined metrics.
If you hit a problem at this point – about 4 hours into a 6-hour window – you’ve usually got an hour or so to fix it before you have to take a go/no-go decision to either move forward, or roll back. In this respect, it’s really not that different from a traditional migration.
Then, in the morning, the users turn up for work
It’s impossible to mimic every single permutation of everyday operations in advance. For all the testing we did, it’s possible a platform might come under more load than anyone ever expected.
If something is going to fail, it’s usually on day two. So we monitor every aspect of performance – disc, memory, CPU, back-up, security, traffic – to see if they are performing within expected parameters.
About 90% of normal operations will occur in the first week from cut over, and month-end processes make up most of the rest. Of course, we’ll have tested for routine operations, batch processes, and month-end processes, but it’s not until the first month is completed on the new platform that you can truly sign off on the migration.
Most enterprises get help with migration
Our recent research into hybrid IT found that 45% of enterprises engage specialist experts to manage migrations. That actually sounds a bit low to me. In my experience, almost everybody does – particularly if the migration involves one of the hyperscale providers.
Cloud encourages a mindset of self-service, but a hyperscaler’s toolset won’t provide the sort of migration support an enterprise needs. And very few clients have all the requisite skills in house. So they use a third-party migration agency.
A good service provider will provide a professional migration service that not only covers their own cloud platform, but extends to third party providers like AWS or Microsoft Azure.