En
Fr
De
It
Es
Uk
How do you modernize legacy software?
Modernize legacy software by first deciding which of five paths fits: keep and stabilise, refactor in place, rebuild module by module next to the old system, replace with an off-the-shelf product, or rewrite from scratch. For most business applications of a 10 to 60 person company, refactoring or a module-by-module rebuild carries the least risk, because the system keeps running while its parts are replaced. A full rewrite fits only small systems or code that cannot be tested at all. With Lytvynov Production modernization work starts from $10,000.
Legacy here means software the business depends on that has become risky or slow to change: an internal ERP written ten years ago, a customer portal on an unsupported framework version, a desktop tool only one person understands. What these systems share is that nobody can change them with confidence.
What are the signs it is time to modernize?
Most companies start too late, when a crisis forces the decision. These signs mean the cost of waiting is already growing:
- The language or framework version no longer receives security updates.
- Small changes take weeks because nobody knows what else will break.
- One or two people hold all the knowledge, and they are busy or leaving.
- Hosting is a single old server that nobody wants to touch.
- New integrations, such as a payment provider, an API for a partner or an AI feature, are blocked by the old stack.
- Staff keep spreadsheets next to the system because it cannot do what they need.
- Auditors, insurers or enterprise customers ask security questions you cannot answer.
Two or three of these are enough to justify an assessment. Our guide on Symfony 6.4 end of life is an example of a deadline that turns a slow problem into a dated one.
What are the five modernization options?
| Option | What it means | Fits when | Main risk |
|---|---|---|---|
| Keep and stabilise | Patch security, add monitoring and backups, document | The system will be retired within 1 to 2 years | Defers the cost, does not remove it |
| Refactor in place | Upgrade language and framework, add tests, clean the worst parts | Business logic is sound and the code can be tested | Slow if there are no tests at all |
| Rebuild module by module | New modules next to the old system, traffic moved one function at a time | The system is large and must keep running | Running two systems in parallel for a while |
| Replace with a product | Move to an off-the-shelf tool and migrate data | Processes are standard for the industry | Paying per user forever, changing how people work |
| Full rewrite | Build a new system and switch over at once | The system is small or truly cannot be reused | Months without new features, a risky single cut-over |
The module-by-module rebuild is often called the strangler fig pattern: the new system grows around the old one until the old one can be switched off. It is the path we recommend most often for internal business systems, because each step delivers working software and can be reversed.
How do you choose? A scoring table
Score your system from 1 to 5 on each line, then read the result below the table.
| Question | 1 | 5 |
|---|---|---|
| How well do the business rules in the code match how you work today? | Mostly wrong | Mostly right |
| Can the code be run and tested on a developer's machine? | No | Yes, with tests |
| Is the platform upgradable, with a supported newer version? | No path | Clear path |
| How standard are the processes it supports? | Unique to us | Industry standard |
| How large is the system? | Very large | Small |
- High scores on rules and testability: refactor in place. Our legacy PHP modernization guide is a step-by-step version of this path for PHP systems.
- Good rules, poor platform, large system: rebuild module by module.
- High score on standard processes: look at off-the-shelf products first.
- Low scores on rules and testability, small system: a rewrite is defensible.
- Planned retirement within two years: keep and stabilise, and spend the budget on the replacement.
Why are full rewrites so risky?
Teams choose the rewrite because the old code is painful to read. The risks show up later:
- Hidden business rules. Ten years of fixes contain decisions nobody documented. The rewrite rediscovers them one bug report at a time after launch.
- A moving target. The business keeps asking for features while the rewrite runs, so the old system has to be changed too, or the new one is already behind.
- No value until the end. Months of budget go out before anything reaches users.
- A single cut-over. Data migration, training and every edge case happen on the same weekend.
A module-by-module rebuild addresses all four. Rules are rediscovered one module at a time with the old behaviour as a reference, new features go into new modules, value arrives with the first switched module, and every switch is small and reversible.
What does legacy modernization cost?
Cost depends on the size of the system, how much can be reused and how much data has to move. These are our typical ranges by scope:
| Scope | Typical work | Timeline | With Lytvynov Production |
|---|---|---|---|
| Assessment and safety net | Code and hosting audit, tests around critical flows, backups, monitoring | 2 to 4 weeks | Part of a project from $10,000 |
| Framework and language upgrade | Supported versions, dependency updates, fixes, deployment pipeline | 1 to 3 months | From $10,000 |
| Rebuild of a small application or portal | New web app with migrated data | 2 to 3 months | $10,000 to $15,000 for a simple web app |
| Module-by-module rebuild of an internal ERP or CRM | New modules, sync with the old system, staged switch-over | 4 to 12 months | $40,000 to $90,000 for a mid-size company |
| Very large multi-platform system | Several applications, integrations and user groups | 12 months and more | $100,000 and up |
A typical US or UK agency quotes roughly 2.5 to 4 times more for the same scope. Running costs often fall after modernization, because one old dedicated server is replaced by managed hosting with backups and monitoring. Our custom software development cost guide covers price ranges for new builds in more detail.
How do you migrate without stopping the business?
The plan we follow for internal systems:
- Map the system. List modules, users, integrations, scheduled jobs and the data each one owns. Interview the people who use it daily; they know the rules the code hides.
- Build a safety net. Add automated tests around the most important flows of the old system, so you can tell when behaviour changes.
- Put a routing layer in front. All requests go through it, so each function can be served by the old or the new code.
- Pick the first module. Choose one that is valuable, fairly isolated and used every day, such as order intake or scheduling.
- Synchronise data. During the transition both systems read and write the same records, through a shared database or a sync job.
- Switch, measure, continue. Move users of one function to the new module, watch errors and feedback for two weeks, then take the next module.
- Switch off the old system once nothing routes to it, after a final data check and an archive.
Where does AI fit into modernization?
In two places. First, AI coding tools speed up the reading of old code: summarising modules, tracing where a rule is applied, drafting tests for existing behaviour. The tests still need a developer who checks them against what the business expects. Second, a modernized system can take AI features that the old one could not, such as reading incoming documents, drafting replies or answering staff questions from the system's data, which is often what finally justifies the budget.
How we modernize business systems
We are a software development company founded in 2020 that builds and maintains internal systems, SaaS products and AI features for companies in the US, UK and EU. We built an ERP for a US aircraft service company that unified client and order management, service scheduling, warehouse and compliance tracking in one platform, and we kept a self-publishing platform evolving in production for two and a half years through 120 database migrations.
Every modernization project starts with an assessment of the code, the hosting and the processes, and ends each stage with working software in production. You get a fixed quote after a short scoping call. See our custom software development and PHP development services for how we work.
