Discover
Map every server, dependency, licence and data flow. Automated discovery plus interviews with the people who actually run the systems.
Decide
Per application: retire, retain, rehost, replatform or rebuild. Write the reason down so nobody relitigates it in month five.
Move
Group workloads into waves that share dependencies. Rehearse, cut over in a controlled window, keep a tested rollback.
Settle
Tune performance, close the old site, prove the cost case and hand over runbooks that people can follow at three in the morning.
Discovery is the whole game
Every estate has more running in it than the CMDB says. Old reporting servers, a licence server somebody built in 2013, a jump host that half the finance team depends on. If you plan the migration on the documentation you inherited, you will discover the truth during cutover weekend, which is the worst possible time.
Run automated dependency discovery for at least one full business cycle, then validate it with the people who operate the applications. The value is not the inventory. It is the conversation the inventory forces: who owns this, what breaks when it stops, and does anybody still need it.
Choosing the target: colocation, cloud, or both
Cloud is not automatically cheaper, and colocation is not automatically old-fashioned. Steady, predictable, licence-heavy workloads often run better and cheaper on owned hardware in a carrier-dense facility. Bursty, seasonal or data-hungry workloads reward cloud elasticity.
The right answer is usually a split, with a fast private interconnect between the two so latency-sensitive systems stay close to their data. Design the network first: the network decides what is possible, not the other way round.
Wave planning that survives contact with reality
Group applications by dependency, not by department. Anything that talks constantly should move together, otherwise you spend months paying for traffic crossing between old and new sites while performance quietly degrades.
Start with a pilot wave that is low risk but genuinely representative: real users, real data, real integrations. A pilot that only proves a static web server can move proves nothing.
Cutover: rehearse, then rehearse again
A cutover plan is a script with timestamps, owners and named decision points. Who calls the go, who calls the rollback, and by when. Rehearse it against a copy of production until the timings stop surprising you.
Keep the old environment warm long enough to fall back, and be honest about the point of no return: the moment data starts changing in the new location, rollback becomes a restore, and a restore has a very different clock on it.
- Full dependency map validated by application owners
- Licence and contract review, including hardware-locked keys
- Network and interconnect design signed off before wave one
- Backup and restore tested in the target environment
- Disaster recovery runbook rewritten for the new topology
- Freeze calendar agreed with the business
- Rollback plan with a defined point of no return
- Decommission plan for the old site, including asset disposal
Discovery and design
Automated discovery, interviews, target architecture, network and interconnect design.
Foundation build
Landing zones, connectivity, identity, monitoring, backup and security controls in place before anything moves.
Pilot and wave one
Move a representative pilot, harvest the lessons, then run the first production waves.
Bulk migration
Waves at a steady cadence, with weekly reporting on cost, risk and performance.
Decommission and optimise
Close the legacy site, right-size the new estate, and prove the business case with real numbers.
The best datacenter migrations are boring. Boring is expensive to buy and cheap to live with.
Resilience is a design choice, not a product
Moving sites is the cheapest moment you will ever get to fix resilience. Two facilities, independent power and carriers, tested failover and a recovery objective the business has actually agreed to in writing.
Test the failover before you need it, on a normal Tuesday, with the people who would be on shift. A disaster recovery plan that has never been executed is a document, not a capability.
- 01Discovery quality determines migration risk. Everything else is execution.
- 02Design the network and interconnect before choosing the destination.
- 03Move applications in dependency waves, never in departmental batches.
- 04Rehearse cutover until the timings are predictable, and define the point of no return.
- 05Use the move to fix resilience, cost visibility and documentation while you have the budget.
Should we modernise applications during the move?
Rarely at the same time. Migrating and rewriting at once doubles the variables and makes failure impossible to diagnose. Move first, stabilise, then modernise with a clear baseline.
How do we avoid surprise cloud bills?
Right-size after a full business cycle, not on day one, and put cost alerts and tagging in place before the first workload lands. Most overspend comes from lifted-and-shifted machines that were oversized in the old world too.
What about the systems nobody wants to touch?
They get a decision, not an exception. Either they move with a wrapper and tight access control, or they stay in a small, well-defended legacy zone with a written end date.
How long should we keep the old site?
Long enough to prove stability across a full reporting cycle, then close it. Parallel running is the most expensive habit in any migration program.
How Redwind runs these programs
Senior engineers who have done this before, working alongside your team rather than around it. We plan the waves, run the cutovers and leave your people with runbooks they wrote with us.