- Discovery first: know every server, what depends on what, and what each one costs to run.
- Move in small waves, test with a pilot, and have a tested way back for every cutover.
- Right-size and hand over at the end, or the new platform will cost more than it should.
Step 1: Discovery
Build a full inventory of servers and applications. For each one, record what it does, who owns it, how busy it is, and what it talks to. Tools can collect most of this automatically over a few weeks, but talk to the application owners too; they know about the monthly job that only runs on the last Friday.
Look especially for hidden dependencies: licence servers, shared file systems, IP addresses written into configuration files, and DNS names that point to fixed addresses.
Step 2: Wave planning
Group workloads into small batches, called waves, that can move together. Servers that talk to each other constantly belong in the same wave. Agree a downtime window for each wave with the business in advance, in writing.
Start with low-risk systems so the team builds confidence, and keep the most critical systems for later waves, once the process is proven.
Step 3: Pilot
Move one small wave from start to finish, including testing and sign-off by the application owner. The pilot is where you find the surprises: a firewall rule nobody knew about, a backup job that fails on the new platform, a slower link than expected. Fix the process, then move on.
Step 4: Cutover
Move the remaining waves on schedule. Each cutover follows the same runbook, and each has a tested way back if something goes wrong.
Before each cutover, check:
- A recent, tested backup of every server in the wave.
- Monitoring and alerts set up on the target platform.
- DNS changes prepared, with short time-to-live values set a few days before.
- Application owners available to test straight after the move.
- A clear go or no-go decision point, and who makes it.
- A rollback plan that has been rehearsed, not just written.
Step 5: Optimise and hand over
Servers on old platforms are often given far more CPU and memory than they use. After a few weeks on the new platform, measure real usage and right-size them. Then automate routine tasks, update documentation and hand over to the team that will run the platform day to day.
Skipping right-sizing is the most common reason a new platform costs more than expected. It is also the easiest saving to make.
Common mistakes
- Moving everything at once. One large cutover turns small problems into a long outage.
- Trusting the inventory spreadsheet. Verify it with discovery tools; it is almost always out of date.
- No rollback plan. Every wave needs a tested way back.
- Forgetting the supporting tools. Backup, monitoring, antivirus and patching all need to work on the target before go-live.
- No owner sign-off. A migration is not done until the application owner says it works.
Planning a move to VCF or the cloud?
We start with a discovery and a wave plan, so you see the effort, downtime and risks before you commit.
Book a free call