Four Ways to Modernize Legacy Code: Replatform, In Place, Rewrite, Replace

The short version

There’s no single “modernize” button. Once a system needs more than a move to new infrastructure, you’re choosing among four paths: replatform (move to a modern platform or language, keep the behavior), modernize in place (improve the code where it lives), rewrite (rebuild from scratch), and replace (retire it and adopt a packaged product).

The right one depends on the condition of the system, the outcome you need, and how much change the organization can absorb. You pick per system, not once for the whole portfolio.

Wherever code has to be converted or transformed and still behave like the original, deterministic transformation (symbolic AI and enhanced compiler technology, the engine behind DMS) owns correctness, and Gen AI augments the work around it. That split decides whether the result is something you can certify or something you have to hope about.

Why the choice matters more than the tool

Legacy systems aren’t a side problem. Widely cited research from Gartner and Deloitte puts the share of enterprise IT budgets spent just keeping existing systems running at roughly 60 to 80 percent, which leaves very little for the work that moves the business forward. Gartner has also estimated that compounded technical debt can consume more than 40 percent of an IT budget. The cost of standing still doesn’t hold flat. It grows, and the more you spend keeping old systems alive, the less you have to invest in getting off them.

The scale is real too. Industry estimates put COBOL alone in the tens of billions of lines still in production, and that’s before PL/I, Assembler, RPG, and the early C and C++ that now counts as legacy. These systems run payrolls, settle trades, and process claims, and the people who understand them are retiring.

Here’s the part teams get wrong. They pick a tool or a vendor before they’ve picked a strategy, and the strategy is what determines cost, risk, and whether the result is worth having. A phased program that fixes the highest-impact systems first commonly reaches positive return in about 12 to 14 months, while a full rewrite can take 36 to 48 months before it pays back, if it ever ships. Same goal, very different bets. So the first decision is which of the four paths fits this system. The platform and the tooling come after that.

The full spectrum, from least change to most

Modernization options are usually described as the “6 Rs,” a hybrid of Gartner’s original framework and the terms most cloud teams use. They run from touching almost nothing to rebuilding everything:

Encapsulate. Wrap the existing system in an API so other software can reach its data and functions. The internals don’t change at all.
Rehost (lift and shift). Move the system to new infrastructure, usually cloud, with no code change. Fastest and lowest risk, and it carries forward all the existing technical debt. Rehosting can trim infrastructure costs by around 20 to 30 percent while leaving the application exactly as it was.
Replatform. Move to a modern platform or language with targeted changes, while preserving what the system does.
Modernize in place (refactor and rearchitect). Keep the system roughly where it is and raise the quality of the code and structure.
Rewrite (rebuild). Build the system again from scratch in a modern stack, keeping its scope and specifications.
Replace. Retire the system and adopt a commercial product or SaaS that covers the need.

Encapsulate and rehost are the do-less baseline. They buy time and stop the bleeding, and they don’t fix the code. The four paths that actually modernize the software are replatform, modernize in place, rewrite, and replace, and the rest of this guide takes each one in turn.

Way 1. Replatform: move to a modern platform or language, keep the behavior

What it is. Replatforming moves the application to a modern runtime, platform, or language while preserving its behavior. The classic version is converting COBOL on the mainframe into Java running on Linux or in the cloud, or C into C#. A lighter version keeps the language and swaps infrastructure components, like moving from a self-managed database to a managed service or containerizing services to run on Kubernetes. The architecture and the features stay the same. Where it runs, and what it’s written in, change.

How it works in practice. Serious replatforming of code is automated migration. The source is parsed into a formal structure, transformation rules convert it to the target language or platform, and the output is regenerated as real source. Doing this by hand across millions of lines isn’t viable, and doing it with Gen AI alone produces JOBOL, valid Java that still thinks in COBOL and leaves every maintenance problem in place. The reliable version uses deterministic transformation so the same construct converts the same way across the whole system, with output built to be functionally equivalent to the original.

Best when. The business logic is sound and worth keeping, but the platform or language is expensive, unsupportable, or impossible to staff. You need the new system to behave exactly like the old one, and you need that proven, not assumed.

Where Gen AI and symbolic AI fit. Symbolic AI and enhanced compiler technology do the conversion deterministically. Gen AI augments it by explaining the source, drafting documentation, and helping generate the equivalence tests that confirm the migration held.

Cost: Medium
Time: Medium
Risk: Low to medium
Behavior preserved: Yes, when done deterministically

Way 2. Modernize in place: improve the code where it lives

What it is. In-place modernization keeps the platform and language but raises the quality of the system. This covers refactoring, which improves the internal structure without changing external behavior, and rearchitecting, which changes the architecture to support new capabilities. In practice it means restructuring tangled logic, removing dead code, breaking a monolith into modular services, upgrading deprecated APIs and language dialects, and enforcing standards across the codebase.

How it works in practice. The defining requirement is consistency at scale: applying the same correct change across thousands of files. That’s exactly what rule-based deterministic transformation does. A transformation rule that migrates a deprecated I/O call to its modern equivalent, or that splits a paragraph into a clean function, gets applied the same way everywhere, so the result is auditable instead of a patchwork of hand edits that drift apart. Static analysis with provable properties is what makes these mass changes safe by construction rather than safe by inspection.

Best when. The system still earns its place and the platform is fine, but the code has decayed: it’s hard to change, hard to test, and slowing every release. You want to keep what works and fix what doesn’t, without the cost and risk of a full rebuild.

Where Gen AI and symbolic AI fit. Gen AI is good at finding the targets and explaining what a given routine does, which speeds up planning. The transformation engine makes the actual mass change deterministically, so the modernized code stays consistent across the whole system.

Cost: Low to medium
Time: Medium
Risk: Medium
Behavior preserved: Yes, behavior held while structure improves

Way 3. Rewrite: rebuild from scratch in a modern stack

What it is. A rewrite rebuilds the system fresh, keeping its scope and specifications but reconstructing the implementation in modern, idiomatic code. The aim is a genuine reconstruction of the business logic, not a translation that carries the old structure forward.

How it works in practice. This is the most expensive and highest-risk path. Rewrites take years to complete with many never finishing before the modernization budget runs out. because you’re rebuilding a system whose full behavior nobody completely documented while the old one keeps changing underneath you. The way to de-risk it is incremental: the Strangler Fig pattern builds the new system alongside the old one, routing functionality across piece by piece until the old system can be switched off, rather than attempting a single cutover.

Best when. The existing design genuinely can’t serve the business anymore, the technology is a dead end, or the requirements have changed so much that preserving the old behavior isn’t the goal. Reserve it for when replatforming or in-place work can’t give you what you need.

Where Gen AI and symbolic AI fit. This is where Gen AI is most at home. It generates new scaffolding and drafts components, and most valuably it extracts the business rules buried in the legacy code so they can serve as the specification for the rebuild. Symbolic methods still matter, because characterization tests generated against the original system are how you check that the new build preserves the behavior you meant to keep.

Cost: High
Time: High (36 to 48 months to payback)
Risk: High
Behavior preserved: Only if you build and test for it

Way 4. Replace: retire the system and adopt packaged software

What it is. Replacing means stepping away from the custom system and moving to a commercial product or SaaS that covers the need, then retiring the original based on current requirements. It’s a build-versus-buy decision more than a code project, and it belongs in this list because it’s a real and often correct modernization choice.

How it works in practice. This is the most expensive and highest-risk path. Rewrites take years to complete, with many never finishing before the modernization budget runs out. because you're rebuilding a system whose full behavior nobody completely documented while the old one keeps changing underneath you. The way to de-risk it is incremental: the Strangler Fig pattern builds the new system alongside the old one, routing functionality piece by piece until the old system can be switched off, rather than attempting a single cutover.

Best when. The function isn’t a competitive differentiator and a mature product already does it well. Think payroll, generic CRM, or commodity back-office processes. Paying to maintain custom code for something a package does better is hard to justify.

Where Gen AI and symbolic AI fit. Gen AI helps on the discovery side: extracting what the old system does so you can run the gap analysis, and assisting with the data mapping a migration needs. Symbolic analysis of the existing code traces dependencies and confirms what can be retired safely, so you don’t switch off something another system depends on.

Cost: Variable (licensing plus migration)
Time: Medium
Risk: Medium
Behavior preserved: Behavior changes to match the product

The four ways side by side

Use this to narrow the choice quickly, then read the section for the path that fits.

Approach	What changes	Behavior preserved	Relative cost / time	Best when
Replatform	Platform or language	Yes, when done deterministically	Medium / medium	Logic is sound; the platform or language is the problem
Modernize in place	Code structure and quality	Yes, while structure improves	Low to medium / medium	The system earns its place but the code has decayed
Rewrite	Everything except scope	Only if you build and test for it	High / high	The design can't serve the business anymore
Replace	The whole system	No, behavior matches the product	Variable / medium	A package does the job and it isn't a differentiator

How to choose

A few questions settle most cases. Work through them in order.

Is the business logic worth keeping? If yes, you’re looking at replatform or modernize in place. If the design is a dead end or a package does it better, you’re looking at rewrite or replace.
Is the platform or language the problem, or is the code the problem? Platform or language points to replatform. Decayed code on an acceptable platform points to modernize in place.
Is this function a competitive differentiator? If not, and a mature product exists, replace is often the cheapest answer over time. If it is a differentiator, keep ownership of it and modernize the code.
How much risk can the organization absorb right now? If the answer is “not much,” rehost or replatform first to stop the bleeding and free up budget, then take on the deeper work. A full rewrite is the highest-risk move and the one to defer until the case is clear.

A useful rule from CTOs who’ve done this at scale: stop the bleeding fast with the lighter options on the systems that are draining budget, then put your real modernization effort into the systems that actually differentiate the business. And whatever you choose, audit first. Map the codebase, the dependencies, the data, and the compliance obligations before you commit, because the long tail of edge cases is where schedules die.

Most real programs use all four

A mature program almost never applies one path across the whole estate. You might replatform the core transaction system to get off the mainframe, modernize a few subsystems in place where the code is salvageable, rewrite one module that’s genuinely beyond saving, and replace a commodity function with a product. The skill is matching the path to each system rather than picking a favorite and forcing everything through it.

The thread through all four: wherever code is being converted or transformed and still has to behave like the original, the deterministic engine owns correctness and Gen AI augments the work around it. Replatform and modernize-in-place lean hardest on deterministic transformation. Rewrite and replace lean hardest on Gen AI for discovery, with symbolic methods used to verify behavior and trace dependencies.

Common mistakes, and how to avoid them

Picking the path by fashion, not by the system. Rewrites get chosen because they sound clean, and they’re the riskiest option. Match the path to the system’s condition and the business outcome.
Treating rehost as modernization. Lift and shift moves the problem to a new address. It’s a fine first step to stop the bleeding, and it fixes none of the code.
Replatforming with Gen AI alone and shipping JOBOL. Valid code that still thinks like the old language passes compilation and fails the team six months later. Use deterministic transformation for the conversion and restructure toward idiomatic code.
Attempting a big-bang rewrite. Single-cutover rewrites of large systems are the classic way to overrun and miss. Use the Strangler Fig pattern and move functionality across incrementally.
Replacing without a real gap analysis. The old system quietly does things nobody documented. Extract what it actually does before you trust a package to cover it.
Skipping equivalence testing. On any path that’s meant to preserve behavior, characterization tests that compare the new system to the old are how you prove you didn’t lose something. Build the safety net before you change anything.

Where Modernize Software fits

Modernize Software is built on DMS, which uses symbolic AI and enhanced compiler technology to convert and transform legacy code deterministically, with Gen AI augmenting the discovery, documentation, and validation around it. That makes it the engine for the two paths where correctness at scale is the whole game: replatforming a system to a modern language or platform while preserving its behavior, and modernizing in place with consistent transformation across millions of lines. For rewrite and replace programs, the same toolkit helps on the analysis side, extracting structure and tracing dependencies so the new system or the new product covers what the old one did. If you’re weighing these four paths and want the parts that have to be correct to be something you can certify rather than hope for, that’s the conversation to have.

Talk to Modernize Software

Tell us about the system and what “done” has to mean for the business, and we’ll help you pick the path and map where deterministic transformation and Gen AI each belong.

Frequently asked questions

What are the four main ways to modernize legacy code?

Replatform, which moves the system to a modern platform or language while preserving behavior; modernize in place, which improves the code’s structure and quality where it lives; rewrite, which rebuilds the system from scratch; and replace, which retires the system and adopts a packaged product or SaaS. Two lighter options, encapsulate and rehost, sit below these as ways to buy time without changing the code.

What’s the difference between replatform and rehost?

Rehosting, or lift and shift, moves the system to new infrastructure with no code change, so it carries forward all the existing technical debt. Replatforming moves to a modern platform or language with targeted changes, and for code it usually means an automated conversion that preserves behavior. Rehost changes where the system runs; replatform changes what it’s built on while keeping what it does.

When does a full rewrite make sense?

When the existing design genuinely can’t serve the business anymore, the technology is a dead end, or requirements have shifted so far that preserving the old behavior isn’t the goal. It’s the most expensive and highest-risk path, often 36 to 48 months to payback, so reserve it for when replatforming or in-place work can’t deliver what you need, and de-risk it with an incremental approach like the Strangler Fig pattern.

Can Gen AI do the modernization for me?

Gen AI is strong at the discovery and assistance work: understanding code, extracting business rules, drafting documentation and tests. It’s probabilistic, so it can’t guarantee that converted code behaves like the original, which is why the conversion itself, on any path meant to preserve behavior, should run on deterministic transformation. The strongest programs use both: symbolic AI and enhanced compiler technology for the conversion, Gen AI to augment the work around it.

How do I choose between the four for my system?

Ask whether the business logic is worth keeping, whether the platform or the code is the real problem, whether the function is a competitive differentiator, and how much risk you can absorb now. Worth keeping plus platform problem points to replatform; worth keeping plus decayed code points to in place; dead-end design points to rewrite; commodity function points to replace. Audit the system before committing.

Do I have to pick one approach for everything?

No, and you shouldn’t. Mature programs apply different paths to different systems: replatform the core, modernize some subsystems in place, rewrite the one module that’s beyond saving, and replace a commodity function with a product. Pick per system, based on its condition and its value to the business.

Sources and further reading

Selected references behind the figures and definitions in this guide.

Gartner’s seven modernization options and definitions of replatform, refactor, rearchitect, rebuild, and replace. https://vfunction.com/blog/modernizing-legacy-code-refactor-rearchitect-or-rewrite/
Legacy modernization approaches and the 6 Rs, with definitions and tradeoffs. https://keyholesoftware.com/legacy-modernization-approaches/
Legacy system modernization in 2026: spend on maintenance, ROI timelines, and the stop-the-bleeding rule. https://www.ecinfosolutions.com/post/legacy-system-modernization-in-2026-strategy-cost-roi-for-ctos
Cloud modernization approaches: rehost, replatform, or refactor, with Gartner’s technical-debt estimate. https://vfunction.com/blog/cloud-modernization-approaches-rehost-replatform-or-refactor/
Replatforming and rehosting definitions and when to use them. https://www.altexsoft.com/blog/legacy-system-modernization-approaches/
McKinsey, on Gen AI accelerating application modernization timelines and cutting technical-debt cost. https://www.effectivesoft.com/blog/ai-legacy-code-modernization-migration.html
TechTarget, on the JOBOL problem in COBOL-to-Java conversion. https://www.techtarget.com/searchsoftwarequality/news/252523671/COBOL-programming-skills-gap-thwarts-modernization-to-Java
DMS Software Reengineering Toolkit, technical overview. https://en.wikipedia.org/wiki/DMS_Software_Reengineering_Toolkit
Semantic Designs, legacy software migration services. https://www.semanticdesigns.com/Products/Services/LegacyMigration.html