Single-Cloud First Was the Discipline — Now Let’s Talk About Movement
Series: Cloud Strategy & Modernization
Part 2 of the Single-Cloud First discussion
We’ve talked about Single-Cloud First as a discipline, not dogma. That conversation centers on architectural philosophy — avoiding unnecessary complexity and adopting multi-cloud only when the business truly requires it. But the next question organizations actually struggle with isn’t philosophical. It’s operational.
How do we move?
Cloud Strategy Is Workload Strategy
Most companies aren’t stuck because they don’t know the cloud exists.
They’re stuck because they don’t know:
- What should move
- What should stay
- How to decide
- How to sequence the journey without breaking the business
This is where cloud strategy shifts from platforms to workload intent.
The real unit of decision isn’t cloud vs on-prem.
It’s: Application + Data + Dependency + Business Impact
Why Do Companies Still Keep a Datacenter?
Despite the narrative that “everything should be in the cloud,” many organizations still maintain a local or rented data center footprint. And not by accident.
Typical reasons:
- Latency-sensitive systems tied to physical processes
- Licensing or legacy platforms that don’t translate cleanly
- Data gravity or regulatory placement requirements
- Operational risk of moving highly stable systems
- Cost structures that don’t favor re-platforming
Keeping a datacenter isn’t a failure. Keeping one without a clear role is. Your datacenter should exist by design — not by default.
The Real Migration Questions
This is where most strategies stall. The questions shift from where to run something… to how to move responsibly.
- How do we evaluate what should move vs stay?
- How do we avoid creating permanent hybrid sprawl?
- How do we modernize without destabilizing operations?
- How do we manage what ends up in both environments?
This is not a product problem. This is an operating model problem.
The Movement Framework
Cloud adoption should follow intentional sequencing:
Assess → Classify → Stabilize → Migrate → Modernize
1. Assess
Understand what exists — dependencies, integrations, operational ownership.
2. Classify
What service class is this workload?
Business criticality determines architecture.
3. Stabilize
Don’t migrate chaos. Fix fragility first.
4. Migrate
Move the right workloads in the right order, not all at once.
5. Modernize
Cloud is the platform — modernization is the value.
Some Workloads Shift Left. Some Shift Right.
Not everything moves forward.
| Shift Left | Modernize and refactor |
| Shift Right | Retire, replace, or consolidate |
| Stay Put | Right where they are — intentionally |
That’s strategy. Not inertia.
The Hidden Risk: Hybrid by Accident
Hybrid environments fail when they emerge organically without governance.
The risk isn’t the hybrid itself. The risk is permanent sprawl without classification. Cloud doesn’t remove complexity.
It changes where it lives: Cost models, identity, security boundaries, observability, and operations.
The Real Shift
The move to the cloud is not a forklift event. It’s a series of deliberate workload decisions tied to:
- Service class
- Business tolerance for failure
- Operational readiness
- Long-term cost curve
This is the same discipline we used when designing service classes in traditional infrastructure. The tools changed. The thinking didn’t.
Where This Fits in the Series
This builds directly on our earlier discussion:
Single-Cloud First: Discipline, Not Dogma
That article focused on architectural restraint. This one focuses on movement and decision-making. Because cloud maturity isn’t about how many environments you run. It’s about how intentionally you decide.
Next in the series:
How governance, platform engineering, and operating models evolve once movement begins.
Explore the full series:
michaelearls.com/cloud