What if you could move a legacy application to the cloud in weeks, not years, without tearing it apart and rebuilding it from scratch? That is the promise behind replatforming, the middle path in cloud migration that sits between a straight lift-and-shift and a costly full rewrite. The trouble is that “replatforming” gets thrown around so loosely that teams often disagree about what it even means before the work begins. A clear cloud replatforming framework fixes that. It gives you a shared vocabulary, a repeatable sequence of steps, and a way to measure whether the move actually paid off. (Cloud computing)
What Is a Cloud Replatforming Framework?
A cloud replatforming framework is a structured method for moving an application to the cloud with limited, targeted modifications. Instead of rewriting code from the ground up, you change a few high-value components: swap a self-managed database for a managed service, replace a hand-built message queue with a cloud-native one, or move file storage to object storage. The industry sometimes calls this “lift, tuck and shift” because you lift the app, tuck in a few improvements, and shift it.
The framework part matters. A framework tells you which applications qualify, what changes are allowed, how to test, and when to stop. Without one, replatforming quietly turns into an open-ended refactor, and budgets disappear.
Where Replatforming Fits Among the Migration Strategies
Most frameworks borrow from a well-known taxonomy of migration options. The original set of six strategies is often called the 6 Rs: retire, retain, rehost, replatform, refactor (or re-architect), and repurchase. Some cloud providers add a seventh, relocate, which covers moving whole virtualized environments without changing them, giving the so-called 7 Rs.
The labels vary between vendors, so it helps to state which taxonomy your team is using before a planning meeting turns into a vocabulary debate. Here is how the main options compare:
| Strategy | What Changes | Typical Effort | Best For |
|---|---|---|---|
| Rehost | Almost nothing | Low | Quick data-center exit |
| Replatform | A few components | Medium | Apps with clear quick wins |
| Refactor | Code and architecture | High | Strategic, high-value systems |
| Repurchase | Vendor product | Medium | Commodity functions like email |
| Retain | Nothing yet | None | Apps not ready to move |
| Retire | App removed | Low | Duplicate or dead systems |
Replatforming earns its place because it captures most of the cloud benefit, such as managed backups, patching, and scaling, for a fraction of a rewrite’s cost. The trade-off is that it can leave technical debt in place. A framework keeps that trade-off visible.
The Core Phases of a Replatforming Framework
Most credible frameworks, whether vendor-published or homegrown, follow a similar arc. The sequence below is the practical version that teams actually use.
Phase 1: Discover and Inventory
You cannot replatform what you have not catalogued. This phase means listing every application, its dependencies, its data stores, and its owner. Teams routinely skip the dependency mapping and then discover a hard-coded connection to an on-premises server halfway through cutover. A disciplined inventory is the single highest-leverage step; if you want a starting checklist, this guide on what to inventory before a cloud migration covers the details. (What is cloud migration?)
Phase 2: Assess and Classify
Next, score each application against criteria such as business criticality, technical debt, licensing constraints, and expected cloud benefit. The output is a simple decision: rehost, replatform, refactor, retain, or retire. Resist the urge to replatform everything. The best candidates are usually apps with a clear managed-service swap available and a business owner who wants the move.
Phase 3: Design the Target State
For each replatform candidate, define exactly which components change and which stay. Write it down. A one-page target-state document that names the managed services, the integration points, and the rollback plan prevents scope creep later. This is also where you decide how the workload maps to accounts and networks; the thinking in when to split workloads across cloud accounts is useful for getting that boundary right.
Phase 4: Build and Migrate
Here the actual work happens: provisioning the new services, adapting configuration, moving data, and running parallel tests. Keep changes minimal and reversible. If a cutover fails, you want a path back to the old environment within hours, not days.
Phase 5: Validate and Improve
After cutover, confirm performance, security, and cost against the targets you set in Phase 2. Replatforming often changes the cost profile in surprising ways, especially around data movement between services. A method for tracking cloud data transfer costs clearly helps you catch those surprises before the first invoice.
Phase 6: Operate and Review
Finally, hand the workload to operations with updated runbooks, monitoring, and ownership. Then review. Did the replatform deliver the expected benefit? What debt remains? Feed the answers into the next wave.
Established Frameworks You Can Borrow From
You do not need to invent a method from nothing. Several public frameworks provide scaffolding you can adapt.
Vendor adoption frameworks. Major cloud providers publish structured migration methodologies that cover strategy, planning, readiness, migration, and governance. They are living documents that get revised often, so check the current revision rather than citing a single publication date. These frameworks are strong on tooling and weaker on vendor-neutral decision-making.
TOGAF. The Open Group Architecture Framework includes an Architecture Development Method (ADM), a vendor-neutral phased approach that many enterprise teams map their replatforming phases onto. It is heavier than most migrations need, but its governance structure suits regulated organizations.
The Twelve-Factor App. This methodology, first published around 2011, is a practical checklist for cloud-native design. Even in a light replatform, checking an app against the twelve factors reveals which changes will cause pain later, such as storing session state locally or hard-coding configuration.
FinOps practices. Cost management deserves its own discipline. Building a cost model into the business case, rather than bolting it on afterward, keeps replatforming honest. For teams trying to make that discipline land with engineers, making cloud cost reviews useful to engineers offers a workable approach.
Well-Architected guidance. Each major provider publishes a Well-Architected Framework organized around pillars such as operational excellence, security, reliability, performance, cost, and sustainability. Use it as a review lens at the end of each wave, not as a checklist to satisfy at the start.
Practical Tips That Actually Work
Frameworks look tidy on paper. Real migrations are messier. These habits separate teams that finish from teams that stall.
- Start with one wave of three to five apps. Prove the pattern, then scale. A pilot that touches a dozen apps at once usually drowns in coordination.
- Freeze scope per app. Write the allowed changes down and treat additions as a new decision, not a favor.
- Test the rollback before the cutover. A rollback plan nobody has rehearsed is a wish, not a plan.
- Assign a single owner per application. Shared ownership is the most common cause of silent delay.
- Watch the data layer. Database swaps are where replatforming projects most often stumble, because schema, latency, and licensing all interact.
- Keep a decision log. Six months later, nobody remembers why a component was left alone. The log answers that.
Common mistakes are predictable too. Teams replatform an app that should have been retired. They assume managed services remove all operational work, then discover patching is gone but capacity planning is not. And they forget that a new cloud region or service launch can change the calculus mid-project; reading a cloud region announcement carefully can save a redesign.
Building the Business Case
A replatforming framework is only as good as the case behind it. The strongest business cases compare three options side by side: rehost now and refactor later, replatform now, or refactor immediately. Each has a different cost curve. Rehosting is cheapest up front but often leaves you paying for inefficiency. Refactoring delivers the most long-term value but ties up engineering capacity for quarters. Replatforming usually sits in the middle, delivering meaningful benefit within a single budget cycle.
Include the less obvious costs: training, tooling, dual-running during cutover, and the engineering time spent on coordination. These are the line items that turn an optimistic estimate into a realistic one. A framework that ignores them will lose credibility after the first overrun.
Governance Without Bureaucracy
Governance gets a bad name because it usually means approvals. In a replatforming framework, it should mean visibility. A lightweight model works: a short weekly review of the wave plan, a shared register of decisions and risks, and clear thresholds for when a change needs escalation. Anything heavier tends to slow the work without improving the outcome.
Security deserves a fixed seat at that table. Moving to managed services changes your shared-responsibility boundary, and teams sometimes assume the provider now handles more than it does. Review identity, network boundaries, and data classification for each app as part of the design phase, not as an afterthought. The broader discipline of enterprise AI and cloud security is a useful reference for how those boundaries are drawn.
Conclusion
A cloud replatforming framework is less about technology than about discipline. It gives a team a shared language for the 6 Rs and 7 Rs, a phased sequence from inventory to review, and a way to keep scope from quietly expanding. The pattern that works is consistent: catalog thoroughly, classify honestly, design a narrow target state, migrate in small waves, and measure the result against the case you made. Replatforming will not rescue an application that should be retired, and it will not replace a genuine refactor where one is needed. What it does well is capture most of the cloud’s operational benefit at a fraction of a rewrite’s cost, provided the framework around it holds. Start with one wave, write down what you are changing, and let the results guide the next.
FAQ
What is the difference between rehosting and replatforming?
Rehosting moves an application to the cloud with almost no changes, often called lift-and-shift. Replatforming makes a few targeted changes during the move, such as swapping a self-managed database for a managed service. Replatforming takes more effort but captures more cloud benefit.
Is replatforming the same as refactoring?
No. Refactoring, sometimes called re-architecting, changes the application’s code and structure substantially. Replatforming keeps the core application intact and changes only selected components. Refactoring delivers more long-term value but costs far more time and engineering capacity.
How many of the 6 Rs should a team use?
Most teams use three or four in practice: rehost, replatform, refactor, and retire. The full set exists to make sure every application gets a deliberate decision rather than a default. Some providers add relocate as a seventh option, so confirm which taxonomy your organization follows.
How long does a replatforming project take?
It depends on the application, but a single app in a well-run wave often takes weeks to a few months. The first wave is always slowest because the team is building its pattern. Later waves speed up considerably once the framework, tooling, and review process are established.
What is the biggest risk in replatforming?
Scope creep. A replatform that starts as a managed-database swap can quietly become a full rewrite if nobody enforces the allowed-changes list. The second biggest risk is skipping dependency mapping, which surfaces hidden connections to on-premises systems during cutover.
Do we need a formal framework like TOGAF to replatform?
Not necessarily. TOGAF’s ADM suits large, regulated enterprises that need heavy governance. Smaller teams often do better with a lightweight six-phase framework plus a checklist such as the Twelve-Factor App. What matters is that the method is written down, agreed, and followed consistently.
