Legacy System Modernisation: Four Routes and How to Choose

The system still works. That is exactly the problem, because nobody will fund replacing something that works until the week it stops.

We have had this conversation for eight years, across 730+ projects and 25+ verticals. It starts the same way. Finance cannot get a report out. Sales wants stock figures on a phone. Whoever wrote the thing left in 2014. And the quote on the table is for a rebuild, the dearest route and the one most often abandoned before it finishes.

The four routes compared

There are four practical routes to legacy system modernisation: encapsulate, replatform, refactor and rebuild.

1. Encapsulate

Cost: Lowest
Time: Weeks
Risk to operations: Very low, because the old system remains untouched.

Choose this route when: Data will not come out of the existing system, but its underlying business logic is still correct.

Avoid this route when: The platform itself is losing security updates.

2. Replatform

Cost: Low to moderate
Time: Weeks to months
Risk to operations: Low, typically involving one cutover weekend.

Choose this route when: The hardware or operating system is out of support, but the application itself is still fine.

Avoid this route when: You expect moving platforms to fix slow or poor-quality code.

3. Refactor

Cost: Moderate to high
Time: Many months
Risk to operations: Moderate and spread across the project.

Choose this route when: The code has become unmaintainable, but the business process it represents is still correct.

Avoid this route when: Nobody can own a routing layer for a year.

4. Rebuild

Cost: Highest
Time: A year or more
Risk to operations: Highest, particularly around go-live.

Choose this route when: The business process itself is changing.

Avoid this route when: Any of the rebuild conditions explained later in this article are missing.

AWS Prescriptive Guidance names seven strategies: retire, retain, rehost, relocate, repurchase, replatform and refactor. We collapse them to four, because four is what a board can hold in its head.

Route one, encapsulate, and why it is usually the honest answer

Put a documented interface in front of the old system and leave the old system where it is. You write an API layer, or now more often a Model Context Protocol server, that reads and writes the legacy database and logic. Everything new attaches to that layer. The 20 year old application keeps posting invoices as before.

We recommend this more than any other route, and more often than most vendors will admit, because it does not generate a large project. Most briefs that arrive as "we need to replace this system" are really "we cannot get our data out". Different problems, very different price tags.

MCP matters here. It is an open standard for connecting AI applications to external systems, described by its maintainers as a USB-C port for AI applications, and it is no longer one vendor's protocol. Anthropic contributed MCP to the Agentic AI Foundation under the Linux Foundation, announced on 9 December 2025, with Block and OpenAI contributing too. A wrapper over a 2006 ERP is not a bet on one AI company surviving.

It fixes integrations, mobile and web front ends, reporting, and controlled AI access to records trapped in a desktop application. It does not fix an unsupported operating system, a data model holding three versions of the same customer, or a database that buckles at 200 users.

Mechanics: MCP for ERP.

Delivery: MCP integration services.

Route two, replatform, same logic on new infrastructure

Replatform means moving the application to supported hardware, a supported operating system or a cloud instance, with minimal code change. AWS calls it lift, tinker and shift.

The trigger is almost always a support date. Windows Server 2012 and 2012 R2 reached end of support on 10 October 2023, and the Extended Security Updates that bought people time run out on 13 October 2026. A dated problem, not a philosophical one.

It fixes patching, backup, disaster recovery and the cost of a server nobody wants to touch. It does not touch the code. A slow report stays slow.

Visual Basic 6 applications usually survive a replatform, because Microsoft still supports the VB6 runtime for the lifetime of supported Windows versions, including Windows 11 and Windows Server 2025. The VB6 IDE is another matter, unsupported since 8 April 2008. You can keep it running. You cannot safely change it.

Visual FoxPro users have less room, since extended support for Visual FoxPro 9.0 ended on 14 January 2015. Replatforming FoxPro buys an environment, not a future.

Route three, refactor, module by module behind the same interface

Refactoring means rewriting the system in pieces while it stays in production, with a routing layer deciding which requests go to the old code and which to the new.

This is the strangler fig pattern. Martin Fowler named it after the strangler figs he saw in the rain forests of Queensland in 2001, and his write up was last revised in August 2024. New code grows around the old system function by function, so the old one is removed rather than switched off overnight.

It works. In our delivery experience it also fails more often than the other routes, rarely for technical reasons.

Four disciplines matter.

A routing layer somebody owns. Every request goes through one place that decides old or new. Once teams bypass it, you run two systems with no referee.

Two test suites, live at once. Both need to be checked on every release for the whole period.

A named business owner per module. Not IT. The person who signs off that purchase orders still work.

No module is ever "nearly done". It is in production or it is not.

In our delivery work a mid sized ERP of 15 to 25 modules takes many months of continuous effort, and sequencing matters more than coding speed. Start with read heavy modules such as reporting screens, where a mistake is visible and reversible. Financial posting goes last.

Route four, rebuild, and the three conditions

Rebuild from scratch only when all three of these are true at once. Not two.

1. The business process is changing, not just the software

Run the same process and a rebuild reproduces your existing rules at maximum cost. Redesign it and the old code has nothing worth keeping.

2. The data model is wrong, not merely old

Old is fine. Wrong means it cannot represent something the business now does, and extra columns will not fix it.

3. A sponsor and a full budget survive the whole thing

One person with authority who still holds the brief in 18 months, and money approved for the entire scope, not phase one.

Half funded rebuilds are the dearest outcome here, because you pay for the new system while still paying for the old.

Note what is not on the list: a vendor deadline.

SAP has confirmed that mainstream maintenance for Business Suite 7, including ECC 6.0, ends at the close of 2027, with optional extended maintenance from 2028 to the end of 2030 at a premium of two percentage points on the maintenance basis.

That is years of runway, enough to encapsulate first and decide properly. Rebuild versus buying a product is a separate question, set out in custom software vs SaaS.

Legacy system modernization: matching your condition to a route

Find your situation below. The recommended route is where we would start.

Vendor support has ended

Start with: Route 2, then reassess.

Why: Get onto a supported platform first. The code question can wait.

Nobody understands the code

Start with: Route 1.

Why: Wrapping needs no knowledge of the internals. Rewriting needs all of it.

A compliance or audit gap was raised

Start with: Route 2 or Route 3, scoped specifically to the gap.

Why: Fix the finding. Do not use it to justify an unnecessary rebuild.

The system crawls at month end

Start with: Route 2, followed by Route 3 on that module if necessary.

Why: Infrastructure is often the problem, and testing that first is cheaper.

You cannot integrate it with anything

Start with: Route 1.

Why: This is the textbook encapsulation case.

Every small change costs a fortune

Start with: Route 3.

Why: Change cost is a code-quality problem.

The process is being redesigned outright

Start with: Route 4.

Why: Rebuild only if all three rebuild conditions hold.

On the compliance line, plainly: we do not hold CERT-In empanelment. You commission the empanelled auditor directly, and we build to that auditor's requirements and implement every finding.

ISO 27001 implementation is underway, an auditor has been appointed, and certification is targeted for Q1 2027, January to March. ISO 9001 is in progress. Neither is held.

Data migration, the part that overruns

Every modernisation programme we have seen run late ran late because of data, not code.

Fix master data before you move it

Customers, suppliers, items, chart of accounts.

Deduplicate in the old system while people who recognise the records are still looking at them. Dirty master data in a clean new system produces a dirty new system by week three.

Split history into migrate and archive

Open items must migrate, with enough closed history for comparison reporting, commonly the current and previous financial year.

Everything older goes to a read only archive with a search screen.

Retention is satisfied by the archive. Loading it all into the live database is what makes go live weekends run to Tuesday.

Reconcile on control totals

Trial balance, stock valuation, open order value, receivables ageing.

Figures that must match to the rupee.

Run the migration three times against production copies first, and expect two failures.

Running both systems in parallel

Parallel running avoids betting the business on one weekend. Eight weeks end to end is our normal shape for a mid sized ERP.

Weeks 1 to 2

What runs: The old system remains live while the new system is shadowed with copied data.

Who does what: IT loads the data. Users do not enter anything into the new system.

Exit test: The new system reproduces last month's reports.

Weeks 3 to 4

What runs: Both systems are live, with dual entry in one department.

Who does what: That department enters transactions twice, while finance reconciles the results daily.

Exit test: Control totals match for 10 working days.

Weeks 5 to 6

What runs: Both systems remain live, with dual entry in every transacting department.

Who does what: Department heads sign the reconciliation daily.

Exit test: No unexplained variances for 10 working days.

Weeks 7 to 8

What runs: The new system becomes the system of record. The old system becomes read only.

Who does what: Users work only in the new system.

Exit test: One clean month end close.

Week 9 onward

What runs: The old system remains available for enquiry only, with no writes.

Who does what: IT plans decommissioning and archive arrangements.

Exit test: The retention plan is signed off, then the old system can be switched off.

Two things people get wrong.

Finance reconciles, not IT, because IT cannot judge whether a variance matters.

And the switch off test is agreed in writing before you start, otherwise parallel running becomes permanent and you have doubled your running cost.

Application modernization services: what you are actually buying

Application modernization services cover five things. Check the proposal has all of them.

1. An assessment allowed to conclude "do less"

If it can only recommend a large build, it is a sales document.

2. A route recommendation with the reasoning written down

A new CTO arriving in two years should be able to see why the decision was made.

3. The build

That might be an integration layer, an infrastructure move, a rewrite or an entirely new application.

4. Data migration with reconciliation evidence

The evidence should be signed by the business, not the developer.

5. A decommissioning plan

It should cover retention, archive access and licence cancellation.

This line is most often missing, and it is where the savings come from.

We run these under ERP and CRM solutions when the system of record is modernised, and web application development when the output is a browser front end over existing logic.

What drives the cost, and the timeline

We do not publish price bands in blog posts, because the same brief varies by a factor of ten. Here is what moves the number.

Cost drivers, in rough order of impact:

Functional modules in scope; integrations to external systems; years of history migrated rather than archived; whether the data model is documented; concurrent user load; in region hosting, which we deploy on request on AWS, Azure or Google Cloud Platform billed to you at cost, or on your own on premise servers; and how long parallel running lasts.

Timeline is mostly about people.

How fast the business frees the two or three subject matter experts who know how the process really works decides elapsed time. Not the developers.

Commercial detail sits on our cost page.

Accucia's view

Route one, encapsulate, is our honest recommendation in most cases, and we know what saying that costs us.

An encapsulation engagement is small. A rebuild is many times larger and runs for a year.

Every time we tell a prospect that an MCP layer and a reporting front end will close most of their pain for a fraction of the rebuild quote in their hand, we talk ourselves out of the bigger contract.

We do it anyway, because the alternative is a half finished rebuild in month nine. So we decline rebuilds that fail the three conditions.

We also will not pretend route one is permanent.

It buys a few useful years and stops the bleeding. It does not make an unsupported platform supported.

Anyone selling a wrapper as the answer to everything is selling you something, and so is anyone insisting a rebuild is the only responsible option.

Leaning towards route one?

Our AI Readiness Audit is the sensible next step: fixed scope, two weeks, Rs 2 to 5 lakh, ending in a written route recommendation you can take to your board whether or not you build with us.

Otherwise, get in touch.

Frequently Asked Questions

What is legacy system modernisation?

Legacy system modernisation is updating an older business application so it meets current needs, without necessarily replacing it.

Four routes exist: encapsulate it behind an API, replatform onto supported infrastructure, refactor module by module, or rebuild.

Most organisations need only the first two.

What are application modernization services?

Application modernization services cover assessment, route selection, the build, data migration with reconciliation, and a decommissioning plan for the old system.

A genuine service can recommend the smallest viable change. If the assessment only ever concludes you need a large rebuild, treat it as sales collateral.

Which modernisation route is cheapest?

Encapsulation, by a wide margin.

You write an API or MCP layer over the existing system and leave the old code running, so there is no data migration, no parallel run and no retraining.

It usually takes weeks rather than months.

Can I add AI to an old system without replacing it?

Yes.

An MCP server sits between the AI application and your existing database and business logic, giving controlled read and write access.

MCP is an open standard, contributed by Anthropic to the Agentic AI Foundation under the Linux Foundation in December 2025.

How long does a strangler fig refactor take?

Longer than anyone budgets for.

A mid sized ERP of 15 to 25 modules takes many months of continuous work, because each module needs a routing decision, two test suites and a named business owner.

Sequencing matters more than coding speed.

Should I rebuild my ERP or modernise it?

Rebuild only when three things are true together:

The business process itself is changing, the data model cannot represent what you now do, and one sponsor plus full budget survives 18 months.

If any is missing, encapsulate or refactor instead.

What happens to my VB6 or Visual FoxPro application?

Microsoft supports the VB6 runtime for the lifetime of supported Windows versions, including Windows 11, but the VB6 IDE has been unsupported since 8 April 2008.

So VB6 applications run, yet cannot safely be changed.

Visual FoxPro 9.0 extended support ended on 14 January 2015.

When does SAP ECC support end?

SAP mainstream maintenance for Business Suite 7, including ECC 6.0, ends at the close of 2027.

Optional extended maintenance runs from 2028 to the end of 2030, at a premium of two percentage points on the maintenance basis, then customer specific maintenance.

How long should I run both systems in parallel?

Around eight weeks for a mid sized ERP: two weeks shadowing, four weeks of dual entry with daily reconciliation, then two weeks with the new system as system of record.

Agree the switch off test in writing before you start.

How much historical data should I migrate?

Migrate all open items and unsettled transactions, plus enough closed history for comparison reporting, commonly the current and previous financial year.

Put everything older into a read only archive with a search screen.

Statutory retention is satisfied by the archive.

Does modernisation help with DPDP compliance?

It can, but do not let it drive the route choice.

India's Digital Personal Data Protection Rules 2025 were notified on 14 November 2025 with an eighteen month phased compliance period.

Most gaps concern consent records, retention and access control.

Who should own the modernisation decision?

A business owner, not IT.

IT can say what is technically possible and what a platform costs to run.

Only the process owner can say whether existing rules should be preserved or redesigned, and that answer decides which route you take.