On-Prem to Cloud Migration

Part 4 named the failure patterns in the abstract. This part puts them in the most common concrete setting: moving systems off hardware you own, in a facility you run, onto cloud infrastructure. “On-prem to cloud” sounds like a relocation, and the marketing makes it sound nearly automatic. It is neither. The compute is the easy part; what makes leaving the data center hard is everything the systems have grown attached to over the years they’ve lived there. This part is about those attachments — what they are, why they resist the move, and how to sequence the work so the move is safe.

Why leaving the data center is harder than it looks

A workload that has run on owned hardware for a decade is not a tidy, portable unit. It has put down roots. It assumes a network it can see end to end. It reaches the file share, the database, the message bus, and the batch job on the next rack as if they were part of itself. It has been tuned to specific hardware. And it depends on behavior that was correct for the data center and is simply absent in the cloud — a shared filesystem, a multicast packet, a fixed IP another system hard-codes.

None of that shows up in an inventory of servers. It shows up the first time you move one workload and three others you didn’t know were connected to it stop working. On-prem migration is, before anything else, a discovery problem: you cannot safely move what you don’t fully understand, and owned-hardware estates are precisely the ones whose dependencies were never written down.

The three things that actually resist the move

Data gravity

Data is heavy. A large dataset is slow to transfer, risky to transfer (Part 4’s unvalidated-migration failure), and — crucially — other systems are attached to it. Move the data and you’ve moved the thing everything else reaches for; leave it and you’ve split a system across two locations connected by a slow link. Data gravity is why migrations sequence around the data, not the applications: you decide where each dataset lives first, then arrange the workloads that depend on it.

Integration dependencies

A long-lived on-prem system accumulates integrations the way a house accumulates wiring — incrementally, by many hands, rarely documented as a whole. Feeds from other internal systems, connections to partners, scheduled jobs that assume things about timing and network reachability. Each one is a thread that has to be re-established, re-secured, and re-tested in the new environment. The migration’s true scope is usually the integration map, not the application list.

Undocumented behavior

The deepest resistance is the behavior nobody can fully explain — the edge cases, the workarounds, the rules encoded in code and configuration that only surface under real production conditions. This is the knowledge-loss failure from Part 4, and it is acute for on-prem systems precisely because they are old enough for the people who understood them to have moved on. You recover this by reading the system itself, not by hoping someone remembers.

The seven Rs, applied to a data-center exit

Discovery tells you what each workload is entangled with. The next decision is what to actually do with it. Not everything that leaves a data center should move the same way, and some things shouldn’t move at all. The industry shorthand for the options is the seven Rs, and the useful part is not the list but the judgment behind picking one per workload.

Before you can assign a disposition, you assess four things about each workload. These come straight out of discovery:

• Coupling. How many other systems reach into it, and how deep. This is the integration map from above, read per workload.
• Data. How large, how sensitive, and how gravity-bound the data it owns really is.
• Change appetite. Is anyone actively improving this workload, or has it been frozen for years?
• Constraint. Any hard latency, data-residency, or compliance rule that caps the options before you even start.

With those four answers, each workload maps to one of seven dispositions:

Disposition	What it means	Choose it when	The trap
Retire	Switch the workload off	Discovery shows nobody depends on it, or a newer system already does the job	Assuming something is dead because it’s quiet. Watch it before you kill it.
Retain	Leave it on-prem, for now or for good	Hard latency, data residency, or flat predictable load make the cloud worse, not better	Retaining by accident instead of by decision (the hybrid failure below)
Rehost	Move it as-is to cloud VMs (lift-and-shift)	The workload is stable, a data-center deadline is real, and re-architecting first would only add risk	Bill shock: on-prem inefficiency now runs on metered cloud pricing
Relocate	Move at the hypervisor level without touching the OS or app	A large VM estate has to leave the building fast and rewriting anything is off the table	A faithful copy of an inefficient estate, cost and all, now with a cloud bill
Replatform	Move it with small changes, such as a managed database under the same app	A cheap, low-risk swap removes real operational toil without a rewrite	“Small changes” quietly becoming a refactor mid-migration
Repurchase	Drop it and adopt SaaS instead	A commodity capability (email, ticketing, expenses) has no reason to be bespoke	Losing custom behavior or data the old system quietly encoded
Refactor	Re-architect the workload to be cloud-native	The workload is strategic and its current shape is what blocks scale, cost, or change	Doing it during the move instead of after the workload has landed safely

The pattern most estates settle into: a long tail of retire and repurchase that shrinks the problem, a bulk of rehost and replatform to hit the deadline, a deliberate set of retain decisions, and a short list of refactor work saved for after the move. The mistake is treating the whole estate as one disposition, usually rehost, and discovering too late that half of it wanted a different R.

The lift-and-shift bill-shock trap

Rehosting is the fastest way out of a data center and the easiest cost mistake to make. On owned hardware, inefficiency is free. An over-provisioned server, a service that idles most of the day, a nightly job on a machine sized for its one busy hour: you already paid for the hardware, so the waste never appears on a monthly invoice. Move that same workload to the cloud unchanged and every inefficiency starts metering. The over-provisioned VM bills for capacity it never uses. The idle service bills by the hour it sits idle. The result is a migration that worked technically and produced a cloud bill larger than the data center it replaced, which is the outcome that turns a project sponsor into a skeptic.

The fix is not to refactor everything before moving, which trades one risk for a bigger one. It is to right-size on the way and to know which workloads earn a replatform. A workload that idles overnight wants autoscaling or a schedule. A database carrying steady load wants a managed, reserved footprint, not an on-demand VM billed at list price. And some workloads should stay on-prem precisely because their load is flat and predictable and the cloud’s elasticity buys them nothing. Cost modeling belongs in discovery, next to the dependency map, not in the first surprised invoice.

The safe sequence: waves, not a weekend

The wrong way to leave a data center is to plan one large cutover for a quiet weekend. The right way is to move in waves, each one teaching you something the next depends on:

1. Discover first. Map the workloads, the data, the integrations, and the undocumented behavior before committing to any move. This is where AI-accelerated analysis earns its place — reading the codebase, data, and configuration directly to surface dependencies a manual review would miss, turning a guessing game into a map.
2. Prove on something low-stakes. Migrate a workload whose failure wouldn’t hurt — a non-critical internal tool, a reporting job. Use it to validate the landing zone, the network bridge to what’s still on-prem, the data pipeline, and the team’s runbook. Mistakes here are cheap and instructive.
3. Migrate to unblock. Sequence the next waves by dependency and value — move the workloads that release others, and the ones whose cloud benefit is clearest, before the hardest.
4. Keep both running. Hold the on-prem environment live until each migrated workload is validated under real production load, with traffic shifted gradually behind a strangler facade and rollback available. The data center gets decommissioned workload by workload, as each one proves out — not all at once on faith.
5. Save the hardest for last. The highest-value, most-coupled, data-heaviest systems move once the team has earned confidence and built the muscle on smaller waves.

Hybrid is a destination, not a failure

There is a quiet assumption that a “complete” migration ends with an empty data center. It often shouldn’t. Workloads with hard latency requirements, strict data residency, or steady predictable load and no elasticity benefit can be cheaper and simpler to keep on owned hardware. The goal is not zero on-prem; it is putting each workload where it runs best.

A deliberate hybrid estate — some workloads in the cloud, some on-prem, connected as one system — is a sound architecture, not a half-finished project. The failure isn’t keeping things on-prem; it’s keeping them there by accident, without having decided. Some workloads can’t move to public cloud at all, for reasons we treat next.

The bridge you have to build first

There is one piece of infrastructure that on-prem migrations consistently under-plan: the connection between what has moved and what hasn’t. The moment you migrate the first workload, you have a hybrid system — a workload in the cloud reaching back to data and services still on-prem, or the reverse. That bridge is load-bearing for the entire duration of the migration, often months, and its properties decide whether the waves go smoothly or stall.

Three things about it bite teams that treat it as an afterthought. Latency: a workload that assumed microsecond access to a local database now reaches across a network link, and chatty designs that were fine on the same rack become slow across the bridge. Security: the link between cloud and on-prem is a new boundary that has to be secured, encrypted, and monitored as carefully as any external connection. Resilience: while the estate is split, the bridge is a single point of failure for anything that spans it. Designing the bridge deliberately — and where possible, sequencing waves to minimize how long any workload depends on it — is part of the migration, not a detail to sort out later.

The honesty required is about the data, not the compute

On-prem migration is where lift-and-shift is most often genuinely correct — a closing data center is a real deadline, and rehosting stable workloads to hit it is sound (Part 3). The honesty required is about the data and the dependencies, not the compute. Teams routinely underestimate the migration by counting servers and ignoring the integration map and the undocumented behavior, then discover the real scope mid-flight. The move is rarely as simple as it looks, and rarely as catastrophic as the horror stories — provided you do the discovery before you start moving things, not after something breaks.

Where this leads

Most on-prem workloads can reach public cloud once you’ve done the discovery. Some cannot — by regulation, by classification, or by a hard requirement to stay disconnected. Those workloads still need modernizing, often urgently, and the standard playbook assumes a public cloud they’re not allowed to touch. Part 6, Air-Gapped and On-Prem Modernization, is about modernizing the systems that can’t leave the building.