Migrating a legacy system without stopping the business

The system was built ten, fifteen years ago. In old PHP, in Delphi, in an Access database someone set up and kept growing. It still runs the company: billing, inventory, customer records. But only one person knows how to change it, it doesn't open on a phone, and it doesn't talk to WhatsApp or the payment gateway. Every small change becomes a project.

You're not alone. In October 2025, Pega published a survey of more than 500 IT leaders at companies in several countries. 78% agree that the time and money spent maintaining old systems would be better used elsewhere. And only 9% said they had reached the point of retiring all of them. Migrating is hard for everyone. The difference is in how the switch is made.

When a legacy system becomes a risk

An old system isn't a problem because it's old. It's a problem when it starts costing too much or threatening operations. The most common signs:

• Only one person knows how to change it. If they leave, get sick or disappear, the business stops.
• The technology no longer gets security fixes. A flaw found tomorrow won't get an official patch.
• Every integration is a workaround. Spreadsheets exported by hand, bots copying screens, double data entry.
• It doesn't work outside the office. No access from a phone or a browser.
• Every change takes weeks. And something always breaks somewhere else.

The second item has a set date for a lot of people. According to the official PHP table, version 8.2 stops receiving security fixes on December 31, 2026. Versions 8.1 and earlier no longer even appear on the list of supported versions. If your system runs on one of them, it's already exposed or will be in less than three months.

The cost of waiting has been measured too. The 2022 report from CISQ, a software quality consortium, estimated the technical debt accumulated in the United States at US$1.52 trillion, and called it the biggest obstacle to changing existing systems. In your company, it shows up as the simple request that never gets done.

Why rewriting everything at once usually fails

The temptation is obvious: commission a brand-new system, build it for months and, over one weekend, turn off the old one and turn on the new. It looks clean. In practice, it's the approach that fails most often.

The reason is that the old system holds rules nobody ever wrote down. The discount that only applies to one type of customer. The tax calculation adjusted after a fine. The exception created for a supplier in 2017. All of it lives in the code, not in the heads of the people asking for the new system. In a rewrite, those rules vanish, and the business only finds out when an invoice comes out wrong.

In 2000, Joel Spolsky, one of the founders of Stack Overflow, wrote a piece that's still a reference on this. He told the story of Netscape, which decided to rewrite its browser from scratch and went almost three years without a new release while losing market share. Martin Fowler, author of classic books on software architecture, says he has seen the plan to replace everything at once “fail most of the time”.

Pega's survey points the same way. The biggest share of the cost of technical debt wasn't in maintaining the old system. It was in how long modernization projects took to finish, and another significant part came from projects that failed because of the old systems.

How to migrate in parts

The alternative has a name in the industry: the strangler pattern, inspired by the strangler fig, which grows around a tree until it can stand on its own. Fowler describes the method like this: the new system is built alongside the old one and takes over one function at a time. When the last part moves over, the old one is shut down without drama.

In practice, the migration follows an order:

1. Inventory. List what the system does, who uses each part, what it talks to and where the data lives. That includes the rules hidden in the code.
2. Data first. Decide what goes into the new database, in what format, and how to check it. Dirty data migrated is still dirty.
3. Pick the first module. Ideally one that hurts day to day and has few dependencies. Sales orders, scheduling or records are usually good candidates.
4. Run in parallel. The new module works alongside the old one for a while. The numbers from both are compared until they match.
5. Switch over that module. Only that one. The rest of the business stays on the old system.
6. Repeat. Module by module, until the old system has nothing left to do. Then it's shut down.

The upside is that each step delivers value on its own. If the budget gets tight halfway through, what's already migrated is live and working. Nobody spends months paying for something that doesn't exist yet.

The safeguards that prevent surprises

A few things decide whether the migration ends well:

• Access in the company's name. Server, database, domain and code need to be under the company's control before you start. It's the same first step for anyone trying to take back a delayed software project.
• A tested backup. Having one isn't enough. Someone needs to restore a copy and see if it opens.
• The people who use it take part. The person in finance knows which report can't be missing at month-end close. They need to test before the switch.
• A written definition of done. Each module has a list of what needs to work and which numbers need to match.
• The cost of running both. During the migration, the business pays for the old system and the new one. That goes into the plan from the start, along with what it will cost to keep the new system live afterward.

How we do it at the Studio

Our rescue work starts with discovery. We read the old system's code and data, list the rules it holds and map out the order of the switch. Only then do we set a fixed price, with a deadline written into the contract. The new system's code, files and access stay in the client's name, and the work is done by our in-house dev team.

Merging and replacing systems that already run operations is work we've done before. At LCX, a travel company operating in more than 10 countries in South America, there was one system per country. They became a single system, live in 29 days.

Every system we deliver ships with an AI agent that runs every day, flags failures, suggests improvements and checks whether the data makes sense. In a migration, that matters: it's what warns you when a number in the new system doesn't match what's expected.

If your company depends on a system nobody can maintain anymore, the Studio's project rescue starts with a discovery of what exists and delivers the migration in parts, without stopping operations.