Where Each Workload Belongs
A data-center exit almost always starts with the wrong sentence: “we're moving to the cloud.” That collapses three different decisions into one — and it's how migrations miss their budgets and their reliability targets. Colocation is your own private cloud in a rented building; public cloud is a different operating model. A per-workload framework for the three doors out of a data center, and the six signals that decide which one each workload takes.
By Tom Ward, Enterprise Architect — Cloud & Infrastructure
Three doors out of the data center
“Get out of the owned data center” is a real goal. “Move to the public cloud” is one of several ways to get there — not a synonym for it. Colocation outsources the facility (power, cooling, physical security, carrier-neutral connectivity) while your hardware — and increasingly a private cloud on it (OpenShift, Azure Local) — stays yours. Public cloud means the provider's hardware and a shared operating model. Every workload faces three doors.
Stay & Modernize
“Nothing changes but the tech”Not every workload should leave, and staying is a legitimate placement — provided you actually modernize in place (virtualize, containerize, refresh) rather than freeze. Belongs here: regulated or sovereignty-bound data that can't legally move; ultra-low-latency or mainframe-adjacent systems; workloads whose migration business case is genuinely negative. Watch out for: “stay” as an excuse to avoid the decision, staying without modernizing, and choosing “stay” when the facility is closing — the one thing this door can't survive is the facility clock.
Colocate
“A private cloud, in a rented building”Colocation's core value is outsourcing the facility — backup power, cooling, physical security, carrier-neutral connectivity — to a specialist who runs it better and cheaper than you can. You keep your hardware, and modern colo is rarely bare metal: you run a private cloud (Red Hat OpenShift, Azure Local) on it, so you also get the cloud operating model while the OS, data, and gear stay yours. Belongs here: workloads that want to offload the facility, not the platform; dedicated hardware or predictable performance; a private-cloud operating model without a public provider. Watch out for: you still own the hardware lifecycle and platform ops, and cross-connect and egress costs that erode the savings.
Public Cloud
“Everything changes: the operating model”The biggest change of the three, because it changes how you operate, not just where you run. The provider owns the facility and the hardware; you consume managed services and share the operating model. Belongs here: cloud-ready workloads with variable or spiky demand; new build and anything you'll genuinely re-platform; services that benefit from managed data, AI, or global reach. Watch out for: lift-and-shift with no re-platform — paying cloud prices for data-center architecture is the single most common cost blow-up in a migration — plus data gravity, egress, and the assumption that cloud is more reliable by default. It's a different failure model, not automatically a better one.
Choosing the door — six signals
Choosing the door isn't a gut call, and it isn't “cloud by default.” Six signals decide where each workload belongs. Weigh them deliberately — the first hard constraint, usually data residency, often closes a door before the rest are even considered.
- Signal 1
Data classification & residency
usually the hardest constraintSensitivity and where the data is legally allowed to live. Decided first — it can close a door before any other factor is weighed.
- Signal 2
Criticality & reliability tier
the nines it owesHow many nines the workload owes. The destination has to be able to deliver that posture — which is where placement hands off to deployment-archetype choice.
- Signal 3
Latency & adjacency
what has to sit near whatChatty call chains hate being split across a WAN; adjacency is why dependent apps move as a group, not one at a time.
- Signal 4
Dependencies — the call chain
map it before you move itThe chain moves together, or you split it and pay in latency and new failure modes. Map it before you move it, not after.
- Signal 5
Cloud-readiness
honest, not aspirationalCan it re-platform, only lift-and-shift, or neither? An honest assessment — not an aspiration — is what separates Door 3 from Door 2.
- Signal 6
TCO of the move
placement without TCO is a guessDoes the business case clear, all-in: migration, run cost, egress, dual-running, and the operating-model change?
The Placement Test
Ten checks before you commit a workload to a door. Score one point per honest “yes.” Below seven, you don't have a placement strategy; you have a default destination and a hope.
- Placement is decided per workload — not a single default destination for everything.
- Data classification and residency are mapped first, and they constrain the door before anything else is weighed.
- Every workload has a reliability tier, and the chosen door can actually deliver it.
- Latency and adjacency are known — chatty dependencies aren't being split across a WAN by accident.
- The full dependency chain is mapped, and it moves together — or the split is deliberate and costed.
- Cloud-readiness is assessed honestly — re-platform, lift-and-shift, or neither — not assumed.
- Each move has an all-in TCO that clears: migration, run, egress, dual-running, and the operating-model change.
- Colo and public cloud are not conflated — a colo private cloud gives you the operating model and keeps control; a public provider runs the platform.
- Placement standards are carried through architecture governance, with conformance, so decisions stay honest over time.
- The facility clock is real and known — lease and exit timelines drive the sequence, and “stay” is only chosen where it's genuinely an option.
Going deeper
Sources worth your time, roughly in the order a team should read them.
- The TOGAF® StandardThe governance and architecture-standards backbone — how placement rules get carried through an ARB and stay conformant.
- Microsoft — Cloud Adoption FrameworkLanding zones and placement guidance for the cloud door — the Door 3 detail this note stays deliberately above.
- AWS — The 6 R's of MigrationRehost, replatform, refactor, and the rest — the migration-strategy vocabulary that lives underneath cloud-readiness.
- Uptime InstituteThe data-center and colocation reliability lens — tiers, facility resilience, and what “your building vs. rented” really buys.
- Red Hat OpenShiftAn enterprise container / private-cloud platform — one way to run the cloud operating model on your own gear in a colo.
- Microsoft — Azure LocalAzure's operating model on hardware you own, at your location — the colo private-cloud option in Microsoft's stack.
- Companion — You Don't Choose Five Nines (Part 4)Once you've chosen the door, the reliability tier picks the deployment archetype. Placement and posture, in sequence.
- Companion — Three Views, One Dollar (TBM)The TCO criterion in depth — how to cost a move honestly, all-in, so the business case isn't a guess.
Part of a four-part arc — read the rest of the playbook.
Back to the playbook