Business softwareMethodCustom softwareSMEsMaintenance
Legacy application modernization: rewrite it all or replace it step by step
10 min read
Legacy application modernization works best for a small or mid-sized company when it does not try to replace everything at once. The safer route is to build the new system next to the old one, move features across one at a time in an order set by value and risk, and switch the legacy application off once it no longer does anything. A full rewrite only makes sense for a small application whose rules are well understood.
Most guides on this topic are written for enterprises with hundreds of applications, a cloud migration programme and an architecture team. This one is for the owner or operations lead of a 10 to 200 person company that runs on one piece of software built a decade ago: an in-house tool, a Microsoft Access database that grew too big, a desktop application whose original developer has moved on. It covers how to choose a strategy, how to split the work, and how to keep invoicing customers throughout.
First, decide whether to rebuild at all
The AWS migration guide groups the options into seven strategies, known as the 7 Rs (checked on 6 November 2026). For a single business application in a smaller company, they boil down to five.
| Option | What you do | When it fits |
|---|---|---|
| Retain | Secure and document it, no rebuild | It works, changes rarely, and someone can still maintain it |
| Retire | Switch the feature or the tool off | Nobody uses it, or another tool already does the job |
| Rehost | Move it to a new server or version, code unchanged | The problem is the infrastructure, not the software |
| Repurchase | Buy an off-the-shelf product or SaaS | The need is standard and your rules fit the product |
| Rebuild | Rewrite it, in one go or in stages | The software carries know-how of its own and holds you back |
These options mix well. You can retire dead screens, move accounting to a standard package, and rebuild only the part that makes your business different. That sorting exercise often halves the scope before any code is written. Our article on build vs buy goes through that reasoning in detail.
Big bang rewrite or step-by-step replacement
Once you have decided to rebuild, the next decision shapes the whole project.
| Criterion | Big bang rewrite | Step-by-step replacement |
|---|---|---|
| First use in production | At the end of the project | With the first module |
| Cutover risk | Concentrated on one day | Spread over several small switches |
| When gaps are discovered | Late, often during acceptance testing | Continuously, module by module |
| Integration work | Low | Real: two systems share the data |
| Option to stop halfway | Poor: nothing usable before the end | Good: each delivered module is kept |
| Best for | Small tool, known rules, clean data | Central, old, poorly documented system |
A full rewrite looks easier to manage: one specification, one project, one go-live date. Its weakness is built in. For months, the business pays for software it cannot use, while the old one keeps changing and the gap widens. Step-by-step replacement asks more of the technical team, but it turns one large bet into a series of small ones you can check.
The strangler fig approach, without the jargon
The name comes from Martin Fowler's article Strangler Fig Application (2024 edition): the strangler fig grows around a host tree until it can stand on its own. Microsoft documents it as an architecture pattern, the Strangler Fig pattern (updated 29 May 2026). For a smaller company, it comes down to three pieces.
A front door that routes requests
Users go through a single entry point: a menu, a portal, a web address. Behind it, each feature is served by either the old or the new system. For users, a migration step looks like one screen changing. With an old desktop application, the front door can be simpler: the new web app takes over one menu at a time while the old program stays installed for the rest.
One owner for each piece of data
This is the technical heart of the approach. During the transition, each piece of data must have exactly one system of record. Three setups are possible:
- the new system reads and writes the legacy database for a while: simple, but it inherits that database's flaws;
- each migrated module owns its data and passes it back to the legacy system where it is still needed;
- two-way synchronisation: avoid it whenever you can, it causes most data inconsistencies.
Microsoft's guidance is explicit on one limit: the pattern may not suit a legacy system whose requests cannot be intercepted, or that has no other integration point you can change, such as its database.
Actually switching off what has moved
A rebuilt feature must be removed from the legacy application, or at least hidden. Otherwise part of the team keeps using the old version, the data drifts apart, and the project never ends. The end goal is explicit: retiring the legacy system on a date that gets closer with each step.
Split by business task, then order by value and risk
Split the application by what people do, not by technical layer. "Order entry", "job scheduling" and "invoicing" are good modules. "The database" or "the user interface" are not: rebuilding one without the other delivers nothing anyone can use.
Then score each module on two axes:
- value: hours saved, errors avoided, a pain point removed, a regulation to meet (e-invoicing mandates are a common trigger in Europe);
- risk: number of business rules, links to other modules, volume and quality of the data involved.
| Value / risk | Low risk | High risk |
|---|---|---|
| High value | Do it first | Prepare early, switch once integration works |
| Low value | Bundle it with a neighbouring module | Retire it or replace it with a product |
The ideal first module is useful, clearly bounded and loosely connected: a customer portal, a mobile screen for field staff, a dashboard that replaces a weekly spreadsheet export. It proves the method, tests the data plumbing, and builds the team's confidence. The core of the system follows once you know that two systems can run side by side.
Keeping the business running during the transition
Done well, modernization is almost invisible to day-to-day operations. Five habits make the difference.
- Switch by scope, not by calendar. One module, then one team, then one site. A small group of willing users goes first.
- Plan the rollback. Before every switch, know how to return to the old way of working within minutes, and which records to reconcile if you do.
- Run parallel checks briefly. For a few days, compare results on sensitive operations: invoice totals, stock levels, schedules. Beyond that, double entry wears people out and must stop.
- Freeze the legacy system, mostly. Bug fixes and legal changes only. New requests go on the list for the new system.
- Train just before, not months before. A short demo the day before the switch beats a general training session nobody remembers.
Data migration follows the same rhythm: module by module, on copies first, with someone from the business checking the results. Our guide to legacy data migration covers it in depth.
Recover the business rules before writing code
A ten-year-old application holds rules nobody remembers and features nobody uses. The two traps mirror each other: dropping a rule that matters, or faithfully rebuilding a feature that is dead.
Three sources help:
- the users, watched while they work, not only interviewed in a meeting room;
- the data: a field left empty for five years points to a dead feature, a free-text field used for something else points to a need the software never served;
- the code, where you have it, for calculations: pricing, discounts, rounding, due dates. An audit of the existing application produces that inventory.
Then validate the target on a clickable prototype: the screens of the future module, shown to the people who will use them, before development starts. A missing field costs minutes to fix on a prototype and days once the module is built.
Mistakes that sink modernization projects
- Copying the old system screen for screen. You rebuild the workarounds it forced on people instead of the actual work.
- Improving everything at once. Ten years of wish lists added to the scope turn a modernization into an endless project.
- Starting with the hardest module "to get it out of the way". Without proven data plumbing, that is where projects stall.
- Neglecting the legacy system meanwhile. It still runs for months: backups, security patches and monitoring still matter.
- Never setting a retirement date. Running two systems in parallel costs more than one, forever.
- No business owner on the project. Someone from your team, with a few hours a week, settles questions about rules. Without them, the developers guess.
Budget, contracts and who owns what
Step-by-step modernization splits naturally into lots, each with its own scope, price and go-live date. That makes it a good fit for fixed-price work: you commit to one module at a time on a validated scope, rather than to one large budget for a year-long project. Our comparison of fixed price and time and materials explains why: on a time-and-materials contract, every week of coexistence is billed by the hour.
For an order of magnitude, Clutch's software development pricing page (updated 21 September 2026) reports, from verified client reviews, a most common project budget of 10,000 to 49,999 US dollars and an average duration of about 13 months. Those are global figures across all kinds of projects, not modernization quotes, and they leave out running costs. Our article on the cost of a custom business application explains what moves a price up or down.
Before signing, check what you get at the end: code, data and documentation, with rights defined case by case in the contract. Our vendor lock-in exit plan lists what to ask for.
Pre-launch checklist
- A list of the legacy application's features, who uses each and how often.
- The sorting: retain, retire, rehost, repurchase, rebuild.
- Modules scored on value and risk, and the first one chosen.
- The system of record for each piece of data during coexistence.
- A prototype of the first module, approved by its users.
- A named business owner with protected time.
- A target retirement date for the legacy system, even a provisional one.
- A maintenance plan for the new system, so you do not end up here again in ten years (see technical debt for business owners).
Where to start
Gather three things: the list of screens or menus your team really uses, an export of the database, and the module that causes the most pain today. That is enough for a first conversation.
At LPR Studio, that conversation leads to a free visual prototype of the first module, presented in a video call within 5 working days, wherever you are based. You see the future screen before committing to anything, and the modernization plan is built from there, one module at a time, on a fixed price or a monthly subscription.