Refactor a legacy system when its business logic is still right and the code can be made testable and changed safely. Rebuild when the platform itself is the problem: an unsupported runtime, no practical way to integrate with the systems you now depend on, or a business process that has changed so much that the old design no longer fits. Between those two sit lighter options, such as moving to new infrastructure or upgrading the runtime, that are sometimes all you need.
Whatever you choose, the safest route is usually incremental. Replacing a system piece by piece behind a stable interface carries much less risk than a big-bang rewrite that must reproduce years of hidden business rules on day one.
This guide helps you decide which path fits, using questions you can answer about your own system, and shows how to migrate without stopping the business.
Signs your legacy system has become a business risk
Age alone is not a reason to modernize. A ten-year-old system that is stable, secure and rarely changed may be the cheapest software you own. Trouble starts when the system blocks the business or exposes it to risk. Common warning signs:
- Unsupported platforms. The system runs on an operating system, database or language version that no longer receives security patches. Windows Server 2012 R2 left extended support in October 2023, CentOS 7 reached end of life in June 2024, PHP 7.4 stopped receiving security fixes in late 2022, and Windows 10 support ends on October 14, 2025
- One person knows how it works. The original developer left, and a single staff member is the only one who can fix month-end problems
- Integration is painful. Connecting to a marketplace, a payment gateway, QRIS settlement reports or your bank requires manual exports and retyping
- Changes take too long. A small request, like a new discount rule, takes weeks because nobody dares to touch the code
- Data is trapped. Records live in Microsoft Access files, FoxPro tables or a desktop database copied between branches
- Browser dependencies. An internal web app only works in Internet Explorer mode in Microsoft Edge
- Regulatory changes hurt. Each new tax or reporting requirement, such as the tax office's move to the Coretax system in 2025, needs another workaround
If two or three of these apply, modernization belongs on your roadmap. If only one applies, a targeted fix may be enough.
The modernization options, from lightest to heaviest
| Option | What changes | When it fits | Main risk |
|---|---|---|---|
| Encapsulate | Add an API layer around the old system | Logic is stable, you only need integration | Old platform risk remains |
| Rehost | Move the same system to new servers or the cloud | Hardware is failing or a server room is closing | Code problems move with it |
| Replatform | Upgrade the runtime or database with minimal code changes | Unsupported versions, but reasonable code | Hidden incompatibilities |
| Refactor | Restructure code in place and add tests | Logic still right, codebase salvageable | Drags on without clear milestones |
| Rebuild | Write a new system and migrate the data | Platform obsolete or process has changed | Scope creep and missed business rules |
| Replace | Adopt an off-the-shelf product or ERP module | The process is standard, like accounting or payroll | Customization limits and license costs |
These options can be combined. A common sequence is to rehost first to remove hardware risk, encapsulate the core with an API, and then rebuild modules one at a time. If you are weighing replacement against a custom rebuild, our guides on custom software vs off-the-shelf and ERP vs custom systems cover that decision in depth.
How to decide: business fit vs technical health
Score the system on two questions. Does it still match how the business works? Can it be changed safely?
- Good fit, good health: keep it, refactor the areas that change often, and add APIs for integration
- Good fit, poor health: the rules are right but the platform is fragile. Replatform if the code allows it; otherwise rebuild incrementally while preserving the logic
- Poor fit, good health: the code is fine but the process moved on. Extend it, or replace the modules that no longer fit
- Poor fit, poor health: rebuild or replace, starting with the parts that hurt most
To place your system honestly, answer these questions:
- Do you have the complete source code, and do you own it? Some older vendor contracts never transferred it
- Can a developer build and run the system on a fresh machine using written instructions?
- Are there automated tests, or is every change tested by hand?
- Is the database schema documented, and is the data reasonably clean?
- Who can explain the business rules, such as discount tiers, VAT (PPN) rounding or special customer terms?
- Which systems depend on it: bank files, tax invoice exports, marketplaces, payroll, branch sync?
Question 5 deserves extra attention. In many legacy systems, the code is the only record of rules that accumulated over years. Before any rebuild, extract those rules into written specifications and test cases, or the new system will be cleaner and wrong.
Migrate in stages with the strangler pattern
The strangler fig pattern, named by Martin Fowler, replaces a system gradually. You place a routing layer in front of the old system, build new modules one at a time, send each module's traffic to the new code, and retire old parts as they fall out of use. The business keeps running throughout.
A practical sequence:
- Map modules and data flows. List what the system does, who uses each part and which data each part reads and writes
- Choose a first slice. Pick something valuable with few dependencies, such as reporting, a customer portal or a mobile app for sales staff
- Build an API facade. Expose the old system's data through an API, so new modules never read its database directly. Our API integration guide explains the patterns
- Keep data in sync. Use scheduled sync or change data capture while both systems are live, with one system clearly owning each record
- Run in parallel and reconcile. Compare outputs daily, such as invoice totals, stock balances or payroll results, until every difference is explained
- Switch over per module. Move users to the new module with a written rollback plan
- Decommission. Archive old data in a readable format and shut the old part down
Plan cutovers around your business calendar. Avoid month-end and year-end closing, and for retail and distribution, the weeks before Lebaran. Each cutover also needs at least one full trial migration, with reconciliation reports signed off by the people who own the data. Where the new modules should run is a separate decision, covered in our comparison of cloud vs on-premise.
Budgeting and contracting the work
Modernization cost is driven by the size of the codebase, the number of integrations, data quality, how long both systems must run in parallel and how much knowledge is still available. Because so much is unknown at the start, begin with a paid discovery phase. As a rough planning range, assuming one core system of moderate size and access to its daily users, discovery takes 2 to 4 weeks and should produce a module map, a risk list, a recommended path and a phased estimate.
Contract structure matters as much as the estimate. A fixed-price discovery followed by phased delivery, priced per module or on time and materials with a cap, usually fits better than one fixed price for the whole rewrite. We compare these models in fixed price vs time and materials.
Above all, do not create the next legacy system. Require source code in your own repository from day one, written deployment steps, documented business rules and a handover plan for your team.
FAQ
Can we modernize without stopping operations?
Yes, in most cases. Incremental migration keeps the old system running while new modules take over one at a time. Short interruptions happen only at each cutover, which you schedule outside peak periods such as month-end closing or the pre-Lebaran rush. A tested rollback plan and a rehearsed data migration keep each cutover small and reversible, so a problem means switching back for a day rather than stopping the business.
Should we rewrite everything in the newest framework?
Choose technology your team or vendor can support for years, not the newest option. Mainstream, well-documented stacks with a large hiring pool in Indonesia are usually safer than fashionable ones. The framework matters less than clean module boundaries, automated tests and written business rules. Those are what make the next change cheap, whichever language the code is written in.
How long does legacy system modernization take?
Plan in phases rather than one deadline. As a rough planning range, assuming a team of three to five people, replacing a first module end to end often takes 3 to 6 months including discovery, parallel running and cutover. Later modules tend to move faster because the API layer, data sync and deployment pipeline already exist. The size of the business rules you must preserve moves the timeline more than the technology.
How Weaveward can build this for you
We would begin with a discovery phase on your current system: read the code and database, interview the people who use it, and map every integration, from bank files to tax invoice exports. The first deliverable is a modernization roadmap with a recommended path per module and the first slice to replace. We then build that slice behind an API layer, run it in parallel with the old system, and switch over only after the reconciliation reports match.
Learn how we approach business system modernization and integration, or talk to our team about the system you are planning to replace.