Data migration strategies and contingency - a case study
Someone (everyone?) once said ‘whatever can go wrong, will go wrong’. For that reason, in our experience, you can never build enough contingency into your data centre migration strategy.
The best laid plans….
You’ve planned your data move. You’ve ticked off everything on your checklist, the dates are set and your data migration service provider is ready to go. Everyone involved is clear about their jobs, so this is going to be executed safely, efficiently and quickly. The departing and receiving data centres are communicating with you and your provider, your in-house team is placed and ready to minimise any disruption and downtime, and any necessary third party logistics are nailed down. What can possibly go wrong?
As a data move service provider, our primary goal is to work with clients to ensure that every detail is in place, and 99% of jobs run like clockwork. However, when things do go awry, it’s inevitably third parties at fault – logistics providers, data centres, airlines, unforseen travel complications etc. It doesn’t take much to make things feel like an out-take from ‘Planes, trains and automobiles’. Third parties aren’t necessarily as invested in this project as much as we and our clients are. Left hands don’t always work with right hands, so it’s our job to build plenty of contingency a coherent data migration plan. And then add some more.
Here’s an example from a recent data centre relocation we undertook. In the best traditions, names and places have been changed to protect anonymity – but the amount of aggravation and travel time hasn’t!
The German Job
Initially, this particular migration was as straightforward as it gets. Our Canadian client, with whom we’ve already undertaken several projects, wanted to relocate 15 server racks from the departing data centre (DC) in Dortmund to the receiving one in Hanover. A simple de-rack and re-rack operation. We had cleared time slots with both DCs and calculated that in an ideal world, this would involve two of our staff driving over the night before, de-racking and re-racking on day two, driving home on day three. As always, we added day four as contingency.
Several days before the migration, our client was informed by the receiving DC that their rental price had dramatically increased making the migration economically unfeasible. As a result, the client decided that the most pragmatic solution was to de-rack then fly the precious cargo back to Toronto. This would involve an audit from a client representative at the departing DC – then we would de-rack, pallet and package the servers ready for their flight. A specialist logistics company based in Leipzig would then collect the pallet from the Dortmund DC under our and the clients supervision. This made our job even simpler – day one drive to Dortmund, day two execute the job and drive home. We added a day three. Just in case – expect the unexpected.
On the day
Our team met the client at 7:30am sharp at the Dortmund DC. After the usual security, we were auditing and de-racking by 8:15. We had all the kit in the loading bay palleted and securely packaged for freighting by 9:15, ready for the arranged 10:15 pickup. Time for a coffee. Then another coffee. And another. By 10:45, still no haulier in sight, we were all getting twitchy (all that coffee probably didn’t help).
A dozen phone calls later, it transpired that the logistics company had the wrong day in the diary. The next available slot that they had was 24 hours later. Perfect. Our pallet was booked on the red eye from Berlin to Toronto the next morning, and here we were stuck on an industrial estate on the edge of Dortmund with a deadline to meet.
The only solution was for us to be logistics on the first leg of the journey, so we decided to drive the pallet to the Leipzig HQ ourselves. The logistics company would then truck it on to Berlin from there.
Leipzig is 417km (or 4-5 hours) from Dortmund, pretty much due east. Home for us was pretty much due west, but it was the only way to keep the migration on track. The client was understandably jittery, so decided to follow us in their hire car and fly to their next meeting in Amsterdam from Leipzig. Maybe not ‘the trains’, but certainly ‘the planes and automobiles’.
After a few traffic jams and going to a wrong address that we were given for the Leipzig HQ (by Leipzig HQ), we safely delivered and signed off our precious cargo at 5:30pm. The client made their meeting, the servers reached Toronto on time and were up and running smoothly 24 hours after that. Our team arrived home on the evening of day three. Contingency (and improvisation) won the day.
Successful data migration – a case study
That could have been the title of this, because it was. Aside from the original DC deciding to hike its prices at the eleventh hour, there was zero unanticipated downtime. Job done, the client was happy, worse things happen at sea etc. Our team are mighty sick of German daytime radio though, and the logistics company got a roasting.
So in the end, it goes to show that contingency is one of the most important tick boxes on your data relocation checklist.