Many companies still depend on systems built years ago. They keep running, but every small change feels risky, the technology is no longer supported, and only one or two people truly understand how it works. At the same time, shutting down operations to replace everything at once is not an option, because transactions, payroll, and customer service have to keep going every day.
The good news is that legacy system modernisation does not have to mean one big overnight switch. With a phased approach, the system can be renewed piece by piece while the business keeps operating. This article walks through the steps, from the initial assessment to managing change within your team.
Why replacing everything at once often fails
The "big bang" approach, building a new system from scratch and switching off the old one on a set date, looks simple on paper. In practice it carries a lot of risk. Legacy systems usually contain business rules that were never documented, so the new system can lose important behaviour that only comes to light after the switch. These projects also tend to overrun, while the old system still has to be maintained until the new one is ready.
When cutover day arrives, all of that risk lands at a single point. If something goes wrong, the whole operation feels it.
Step one: assess what you have
Before writing new code, understand what is currently running. An initial assessment should cover:
- Function map. Which modules exist, who uses them, and how often.
- Dependencies. Which other systems, reports, or integrations rely on the legacy system.
- Data. Database structure, data quality, and which data must move to the new system.
- Hidden business rules. Calculations, validations, or exceptions that exist only in the code.
- Technical risk. Unsupported components, security gaps, and the parts that break most often.
From this assessment you can decide which part to replace first, usually the riskiest part or the one that slows work down most.
The Strangler pattern: modernising legacy systems in stages
The strangler pattern is the most widely used approach for modernising without downtime. The name comes from a vine that grows around a host tree until it eventually takes its place. In software terms, new modules are built alongside the legacy system and take over its functions one at a time.
The pattern usually goes like this:
- Put an intermediary layer, such as an API gateway or proxy, in front of the legacy system so every request passes through one point.
- Pick one bounded function, for example reporting or customer registration, and build its new version.
- Route part of the traffic to the new module, starting with a small group of users.
- Monitor the results and compare them with the legacy system.
- Once stable, route all requests for that function to the new module and retire the old part.
- Repeat for the next function.
This keeps every step small and reversible. The business keeps running, and risk is spread across many small steps instead of one large cutover.
Data migration, testing, and rollback plans
Data migration
Data is the most sensitive part. Move it in batches and validate each one: record counts, transaction totals, and samples checked by hand. During the transition you will often need two-way synchronisation so the old and new systems hold the same data. If the data includes personal information about customers or employees, make sure the process follows your privacy policy and the principles of Indonesia's Personal Data Protection Law (UU PDP).
Testing
Before changing anything, add tests around the legacy system's important behaviour. These tests become the reference that proves the new system produces the same results. One useful technique is running the old and new systems in parallel on the same inputs and comparing outputs before the new system is actually relied on.
Rollback plans
Every stage needs a way back. Decide up front which warning signs trigger a rollback, who has the authority to call it, and the technical steps to send traffic back to the legacy system. The plan should be rehearsed, not just written down.
Managing change in your team
Modernisation is not only a technical job. Users are used to the old system, shortcomings included. Bring them in early: ask which parts cause the most friction, let them try new modules first, and provide a short guide for each change.
The people who know the legacy system best are also a key asset. Involve them in the assessment and testing, because they know the unwritten business rules. Communicate the schedule for each stage clearly so no department is caught off guard.
During the transition, provide a clear support channel as well, such as a single contact or dedicated channel for reporting problems. Log every report and follow up quickly, because users' trust in the new system is built in the first few weeks.
Starting modernisation safely
Legacy modernisation is safest when it starts with an honest assessment, continues in small reversible steps, and is backed by testing and a rollback plan at every stage. Done this way, the system becomes easier to maintain without sacrificing day-to-day operations.
If your system is hard to change, depends on unsupported technology, or is understood by only a few people, the Averoa team can help through our legacy modernisation service, from a system audit through to phased migration and data migration.
