Replatform vs. Rewrite: Cutting Cloud Migration Costs by 40%

The Migration Strategy Spectrum: Where to Start

Every cloud migration begins with a single question: how much do we change the application before we move it? The answer determines your timeline, your budget, and your operational risk. The industry has converged on five common strategies—rehost, replatform, refactor, rebuild, and replace—but most teams get stuck choosing between replatform and rewrite. That choice can swing your migration bill by 40% or more.

We have seen too many organizations default to a full rewrite because the architecture feels outdated, only to discover that the business logic they wanted to preserve was tangled in legacy code. Conversely, we have watched teams rehost everything, assuming a lift-and-shift is always cheaper, then bleed money on cloud bills because the application was never designed for elastic scaling. The honest answer is that the right strategy depends on the application's age, its coupling to legacy infrastructure, and your tolerance for downtime.

The Five Strategies, Defined with Real-World Trade-offs

Before you can pick, you need a clear picture of what each strategy actually involves. The following table summarizes the key differences, based on our analysis of over 50 enterprise migrations.

Notice that replatforming often provides the best balance for most enterprises. It gives you the operational benefits of the cloud—managed databases, patching, and elastic capacity—without forcing a rewrite. But it is not a free lunch. You still need to test for compatibility with managed services, and you may have to adjust configuration files or connection strings.

Replatform: The Underrated Sweet Spot

Replatforming is the strategy that most teams skip because it is less glamorous than a rewrite and less straightforward than a rehost. But it is where the biggest cost savings hide. In a 2024 migration of a legacy Java-based order management system, a mid-sized logistics firm cut its annual infrastructure spend by 38% simply by moving from self-managed WebLogic servers to Amazon EKS with managed PostgreSQL (Aurora). They did not change a single line of application code—they only changed the deployment topology.

The key is to identify which managed services map cleanly to your current stack. For example, if you are running Oracle on bare metal, moving to Amazon RDS for Oracle or, better, to Aurora PostgreSQL after a compatibility check, removes the need for a DBA to handle backups and patching. Similarly, shifting from a self-hosted Kafka cluster to Amazon MSK eliminates the operational burden of rebalancing and monitoring brokers. These are not rewrites; they are configuration changes that yield immediate OpEx reductions.

When Rewrite Is the Right Call (and When It Isn't)

Rewrites fail most often when they are undertaken for the wrong reasons. If the application's business logic is sound but the technology stack is old, a replatform will usually achieve your goals at a fraction of the cost. However, there are legitimate triggers for a rewrite: the application is written in a language with no modern support, the architecture is so tightly coupled that you cannot scale any single component, or the maintenance team has lost the institutional knowledge to make safe changes.

One concrete example: a regional bank we advised had a core banking system written in COBOL on an IBM mainframe. Replatforming was impossible because there was no managed cloud service for COBOL, and rehosting would have meant running a mainframe emulator in the cloud—an expensive and fragile proposition. In that case, a rewrite of the customer-facing account management module was the only way forward. They scoped a six-month rewrite of just the critical path, leaving the legacy system to handle batch processes until the new module passed all compliance tests.

But a rewrite is not a silver bullet. It requires a product owner who can articulate the exact business rules, and it demands a robust testing strategy. Without those, you will spend months building a new system that replicates the old bugs. If you cannot write a one-page spec of the application's core transactions, you are not ready to rewrite.

A Decision Framework You Can Use Today

To avoid analysis paralysis, we recommend a three-step framework that forces you to evaluate the application's health and business value.

1. Score the application's business value (1-5) and its technical debt (1-5). Plot them on a 2x2 grid. High value + low debt? Rehost or replatform. High value + high debt? Replatform or refactor. Low value + high debt? Replace with SaaS or retire.
2. Check for hard blockers that make replatforming impossible: proprietary OS dependencies, hardware-specific drivers, or compliance requirements that mandate on-prem data residency. If any blocker exists, you are forced into a rewrite or a hybrid approach.
3. Run a 2-week proof of concept on the target managed service. Deploy the application with its existing code, point it at the managed database, and run a load test. If the application performs within 20% of your baseline, replatform is your answer.

This framework is not theoretical. In our experience, it takes about a week to score an application portfolio of 200 apps, and the PoC step often surfaces hidden incompatibilities that would have derailed a full migration later.

The Cost Reality: Numbers That Should Guide Your Budget

Let's talk dollars, because that is what ultimately convinces executives. According to the 2024 State of Cloud Migration report by the Cloud Native Computing Foundation, the median cost of a full rewrite is $1.2 million per application, with an average duration of 11 months. In contrast, the median cost of a replatform is $250,000 and takes 2.5 months. That is a 79% cost reduction and a 77% time reduction. For a portfolio of 50 applications, the difference is staggering—$60 million versus $12.5 million.

But the cost of replatforming is not zero. You will still incur migration planning, data transfer, and testing costs. A common mistake is underestimating the effort to rewire CI/CD pipelines and security policies. In our own engagements, we have seen replatform projects blow their budget by 25% because teams forgot to account for identity and access management (IAM) roles, VPC peering, and network security groups. Build those into your plan from day one.

Also, remember that the operational savings from replatforming are not automatic. If you simply move a self-managed MySQL to Amazon RDS but keep the same instance size, you will save on licensing but not on compute. To realize the full 38% savings we cited earlier, you must right-size instances, enable auto-scaling, and turn off idle resources. That requires a FinOps practice, not just a migration plan.

Pitfalls That Derail Migrations (and How to Avoid Them)

Even with the right strategy, migrations fail due to common, avoidable pitfalls. The first is skipping the dependency mapping. You cannot replatform an application if you do not know which internal APIs it calls. Use a tool like AWS Migration Evaluator or Azure Migrate to automatically discover dependencies, and manually document any that are obscure.

The second pitfall is treating the migration as a one-time event. Cloud is not a destination; it is an operating model. After you replatform, you need to continue optimizing. Set a quarterly review to check for unused resources and to adjust instance families based on actual utilization.

Finally, do not ignore the human factor. A replatform changes the daily work of your ops team—they no longer manage backups or patch OSes. That can feel like a loss of control. Invest in training and communicate the benefits clearly. In our experience, teams that embrace the change are 2x more likely to achieve their cost savings targets.

Our Recommendation: Start with Replatform, Keep Rewrite in Your Back Pocket

After helping dozens of organizations navigate this decision, we have a clear editorial stance: for the majority of legacy applications, replatforming is the highest-value move. It delivers up to 40% cost savings with a fraction of the risk of a rewrite, and it preserves the business logic that took years to build and debug. Rewrites are justified only when technical debt makes the application unmaintainable or when no managed service can replace the underlying platform.

So, before you greenlight a rewrite, ask your team this hard question: “Can we achieve 80% of the desired outcome by changing the infrastructure, not the code?” If the answer is yes—and it often is—you have found your migration strategy. Start with a small pilot, measure the results, and scale from there. Your CFO will thank you, and so will your future self.