Welcome to part two of my top tips for successful migrations. In part one yesterday, we discussed how to recognise if your migration team can be trusted with your most precious of commodities; your data.
Today we look at why you shouldn’t use the migration as an opportunity to perform development upgrades.
Whatever the reason for your migration, here is the second of my top five tips for successfully migrating from A to B.
2 – Successful migrations mean doing one thing at a time
It is really, really tempting to try to update everything at the same time. Don’t! You are already going to be changing hardware, DNS, and, if you are upgrading, possibly moving to a newer operating system. Then you get in a developer to make some changes because your web services are going to be offline anyway and you might as well make full use of that downtime, right?
Sure, you might do this and it might work out great. On the other hand, if it doesn’t work and the migration is unsuccessful, how are you going to know what is wrong? If you haven’t actually changed anything, then it is simple; the migration process is causing issues which can be traced and resolved.
On the other hand, if you have developers performing updates while the migration is going on, it is suddenly much more complicated. Questions you will undoubtedly asked include:
“Is it the migration to new hardware?”
“Is it an inconsistent state caused by a combination of old and new versions?”
“Have the developers changed something in such a way that it is now incompatible?”
“Have the developers broken something?”
And, most importantly from your point of view, “who do you blame?”
The migration team will suspect the developers. The developers will suspect the migration team. Meanwhile, your migration AND development bill will be getting bigger and bigger whilst everyone tries to sort it out.
Avoid this completely by doing one thing at a time!
Finally, while you have the migration team at your disposal, consider asking them to perform a second migration of the newly migrated site to a development server that your development team can use for, err, development. The process will be a lot faster and cost effective because your migration team have already performed a successful migration. This server might be a Cloud server which can then become a snapshot and be rebuilt as necessary to avoid ongoing costs when it is not required.
In part three tomorrow, we will discuss why development teams do not make the best migration experts.