How to plan a server migration nobody notices

A migration that goes well looks, from the outside, like nothing happened. That outcome is almost entirely determined before the migration window opens. What happens on the night is execution; what determines success is the four weeks before it.

Step one: find out what you actually have

Every migration begins with an inventory that turns out to be wrong. Accept this early and budget for it.

You're looking for more than servers. You need the dependency map: which systems talk to which, over what ports, using which credentials, and — the one that catches everyone — which external parties have hardcoded your IP addresses into their firewall rules.

• Every server, its role, and its owner
• Every scheduled job, including the ones on someone's workstation
• Every integration, inbound and outbound
• Every certificate and its expiry date
• Every DNS record pointing at anything you're moving
• Every hardcoded IP address you can find, and a plan for the ones you can't

Step two: decide what not to move

A migration is the only time you'll have organisational permission to decommission things. Use it. Every server you retire instead of migrating is a server you don't have to test, cut over, or support afterwards.

The question for each system is simply: if we switched this off today, who would call? If nobody can name a person, you've found a candidate.

Step three: rehearse against a copy

This is the step that gets cut when timelines compress, and it's the step that prevents most incidents.

Build the target environment. Restore a copy of production into it. Run the application. Have real users — not just the infrastructure team — do real work in it for a day. You will find something. You always find something, and finding it in rehearsal costs a conversation rather than an outage.

Step four: write the runbook, then write the rollback

The runbook is the minute-by-minute sequence for the night: who does what, in what order, and what "done" looks like for each step. It should be detailed enough that someone other than its author could follow it.

The rollback plan is the part people skip, and it needs to be equally specific. It must answer three things:

1. What is the exact trigger for rolling back? Define it in advance, in measurable terms, so nobody has to make that judgement call under pressure at 3am.
2. What is the point of no return — the moment after which rolling back is no longer possible? Everyone in the room needs to know when you cross it.
3. How long does the rollback itself take? If it takes six hours and your window is four, it isn't a rollback plan.

Step five: pick the window honestly

The best window is the one with the longest gap before users return, not the one that's most convenient to schedule. A Friday night migration gives you the whole weekend to find problems. It also means finding them with a skeleton team. Choose deliberately, and make sure the people you'd need are actually reachable rather than nominally on call.

Step six: define success before you start

Not "the servers are up." Write a specific checklist: these five business processes complete end to end, these integrations exchange data successfully, these reports produce the expected numbers. Have the people who own those processes verify them, not the migration team.

The week after

Migrations don't end at cutover. Keep the old environment available — powered off but restorable — for at least two weeks. Watch for the delayed failures: the monthly job that only runs on the 1st, the quarterly report, the partner integration that only fires when they send a file.

Then, and only then, decommission. And write down what surprised you, because the next migration will surprise you in exactly the same way if you don't.