Most migration plans we see start with the equipment: which server goes in which van, who drives, what time everything is running again. That is the easy part. The hard part is that you are not moving servers but dependencies — and those are not in the van.
Start with what talks to what
Before anything leaves the building, you want to know which systems need each other in order to come up at all. That is rarely the same as the org chart of your applications.
- Quorum — at start-up a cluster does nothing until a majority of the nodes is back. Work out how many that is and build those first; switching on a few VMs with whatever happens to be there will not do.
- Storage before compute — the storage nodes have to be reachable first. If the compute nodes come up earlier, VMs go looking for disks that are not there yet, and that is never going to work.
- Rebalancing you do not want — put the cluster into maintenance mode before you shut a node down.
- Time — clock synchronisation is a hard requirement for distributed systems. If a node cannot sync its clock, cluster communication becomes unreliable.
- DNS — do not let nodes find each other through a DNS server that runs on that very cluster. That circle only closes once everything is already running.
- Outbound traffic — which systems have to be reachable from the internet, and which addresses are other parties counting on?
That last one is underestimated most often. Customers, payment providers and integration partners have your IP addresses in a firewall or an allowlist — often because you gave them those addresses yourself at some point. Move to different addresses and changing that is no longer technical work but waiting on someone else: a change request, a queue, sometimes a maintenance window. Bring your own IP space with you and that wait disappears — only BGP convergence remains, and that is a matter of minutes. See what is IP transit for how that works. If you cannot take your addresses with you, lower the TTL on your external DNS records well in advance so the switchover does not get stuck in caches — and do not forget those allowlists.
The boot order is the plan
Once you know what depends on what, the order falls into place by itself: network, storage, compute. First the network, then the storage nodes until the cluster reports healthy, then the rest of the nodes, and only after that the VMs and the applications leaning on them.
Three things that often go wrong here:
- Switching everything on at once — if one system then falls over, you are searching ten log files at the same time. Bring them up in blocks and check each block.
- Carrying on while the cluster is still recovering — "up" is not the same as ready. Only let VMs loose on it once it reports healthy, otherwise you are stacking recovery on recovery.
- Assuming a machine boots cleanly — a service that was once started by hand and never configured to come back after a restart is something you discover at the worst possible moment. Test the restart at the old site, where falling back is still free.
Move logically what you do not have to move physically
A cluster whose nodes hang off the same cluster storage moves in one go. Leaving half of it behind is only possible if you can stretch that storage across both sites, and what you get for it is latency and a witness problem — a choice you make in advance, not something you find out on the night of the move.
What you can phase is the logical side, and that is where most of the tension disappears:
- Redeploy stateless components in advance. Load balancers, reverse proxies and workers do not have to go in the van — they are already running at the new site before anything moves physically.
- Set up replication so the data comes along ahead of time. The switchover is then a matter of catching up, not of transferring.
- Decide in advance how you switch the traffic. Via DNS, via an announcement, or by letting the load balancer at the new site take over — each with its own fallback path.
The more you pull forward this way, the smaller the part that genuinely has to happen that night.
What has to be in place at the new site
On moving day you do not want to be configuring anything any more. The basics are already there, and "there" means you have tested it, not that it has been delivered.
The environment:
- The rack — units laid out at the right heights, PDUs connected to both feeds.
- Power — the connected load matches what you are actually going to draw, including planned upgrades.
- Cross-connects — in place and tested end to end, not just patched in.
The network is configured and tested in every part:
- Management — will you be able to reach it later without getting in the car? You test out-of-band access now, not when you need it.
- The local network — VLANs configured, segmentation as intended, and traffic between the segments actually routed.
- Outbound traffic — IP transit or direct internet access, IP space assigned and advertised where needed. Test with real traffic over the uplink; a green light only tells you a cable is plugged in.
Do those tests before a single server moves. On a quiet Tuesday afternoon a network problem is something you work out; on a migration night it is a reason to fall back.
Get your monitoring right in advance as well. It often still points at the old site and then stays silent exactly when you need it — or, more annoying still, runs on the cluster you are migrating.
During a migration in particular you want to see when something goes offline and when it comes back. That is not just for ticking boxes: if something goes wrong halfway through, you notice it because a service that was already running suddenly drops out again. Because someone brushed against a power button while racking, for instance.
Arrange in advance who is coming that night. With us access can be arranged quickly — within five minutes if it has to be — but anyone going in has to be able to prove their identity. Make sure they bring ID.
Only clear up once it has survived a working day
As long as the old setup is still standing and the old connection is still live, falling back is cheap. That reassurance is worth a few days of double costs. Let the new situation run for at least one full working day — including the nightly backup and the monthly batch if it is due — before you disconnect anything.
Migrating with Xyphen IT
We do this on a project basis and take it on from start to finish: mapping dependencies, working out the boot order, setting up colocation and preparing the connections. Our engineers know your environment, so if something does not come up at two in the morning, nobody has to go hunting for a network diagram first.
Want to know what is involved in your case? Request a proposal or get in touch — we will take a look at your current setup.