Lift-and-shift, cold, and phased migration are the three structural approaches to moving infrastructure, and the choice among them sets the cost, the risk profile, and the length of the outage. Make it deliberately, because it is usually settled by default: by whatever the team did last time, or whichever option the first vendor proposed.
The honest inputs are how much downtime the business will tolerate (the maximum tolerable downtime, in NIST SP 800-34 terms), how much duplicate hardware the budget will support, and how much complexity the team can execute. Everything else follows.
What Is a Cold Migration?
A cold migration means shutting everything down, moving the physical equipment, and bringing it back up at the destination.
This is the lowest-cost approach and the simplest to plan. No duplicate hardware, no replication infrastructure, no cutover orchestration. The equipment that was running before is the equipment running after, with the same configuration and the same data, because it is the same machine.
The outage is the entire duration — shutdown, deracking, transport, racking, cabling, power-on, and validation. For a modest environment moving a short distance, that can fit in a weekend. For a large environment or a long haul, it does not.
Cold migration also carries the risk that equipment which was running reliably does not come back. Disks that have been spinning for years sometimes do not survive a power cycle, and hardware that tolerated a stable environment sometimes does not tolerate a truck. That risk is manageable with verified pre-move copies from your IT team and spares on hand, but it is real and it concentrates at exactly the moment when the outage window is already running.
Choose it when the outage is affordable and the budget is not.
What Is Lift-and-Shift to New Hardware?
Lift-and-shift means provisioning equivalent hardware at the destination, having your IT team copy workloads across, cutting over, and decommissioning the source.
The outage shrinks to the cutover itself. Everything before it — provisioning, replication, testing — happens while production continues running. The destination can be validated properly before it carries anything, and the source remains available as a fallback if the cutover does not go well.
That fallback is the real advantage. A cold migration that fails leaves you with equipment in a truck or partially racked at the wrong site. A lift-and-shift that fails leaves you exactly where you started, which is a materially better position.
The cost is duplicate hardware for the overlap period, plus the replication infrastructure and the effort of running two environments. For virtualized and cloud-adjacent workloads this is routine. For physical systems with hardware dependencies, it is more involved.
Choose it when downtime is expensive and capital is available.
What Is a Phased Migration?
A phased migration moves systems in waves over weeks or months rather than in a single event.
Each wave is small enough to plan carefully, execute with the team you have, and validate properly before the next begins. Problems surface early on low-risk systems, and the process improves with each wave. It is by a wide margin the lowest-risk approach for large environments.
It is also the most complex to operate, because for the duration of the program the environment is split across two sites. Applications in one location depend on databases in another. Latency between sites becomes a production concern rather than a migration concern. Network capacity between the two has to carry traffic that was never designed to cross a link.
Phased migration requires a working inter-site network, tolerance for the latency it imposes, and dependency mapping accurate enough to build wave groupings that hold. Move groups that split a tightly coupled set of systems produce exactly the problems the approach is meant to avoid.
Choose it when the environment is too large to move at once and the sites can be connected well enough to run split.
Should You Combine Approaches?
Usually, yes. Real programs rarely use one approach uniformly, and there is no virtue in consistency here.
Tier-one applications with no tolerance for downtime get lift-and-shift to new hardware. Development and test environments, which nobody will miss over a weekend, get cold-migrated to save money. Everything else moves in phases.
Segment by what each system actually requires rather than by what is administratively tidy. The result is a plan with several execution patterns running under one schedule, which is more work to coordinate and considerably cheaper than applying the most expensive approach to everything.
Making the Choice Defensible
Get the downtime tolerance in writing from the business, ideally through a business impact analysis, rather than assuming it. The stated tolerance and the real one frequently differ, in both directions — some systems described as critical can absorb a weekend, and some described as routine turn out to feed something that cannot.
Price the options against each other honestly. Duplicate hardware for a lift-and-shift has a number attached. So does an extended outage, and the business can usually estimate it. Putting both figures in front of the decision-maker converts an argument about approach into a straightforward comparison.
Then write down why the approach was chosen. Six months in, when the schedule is under pressure and someone proposes compressing a phased migration into a single weekend, the record of what the approach was protecting against is what keeps the decision from being quietly reversed.