A business system from ten years ago still runs fine, but it cannot be changed and no one dares to touch it. We have validated this incremental refactoring route in more than a dozen projects; it is much safer than a rebuild.
Almost every enterprise that has been in business for more than ten years has a legacy system it "loves and hates": the business runs on it, but changing one field requires a two-week schedule, and adding one report requires digging through documentation for three days. The boss's first reaction is often "rebuild it," and we usually advise them to calm down first.
Do not rush to overthrow it: legacy systems contain business truths
Although the code is old, the business rules inside were forged over more than a decade of real money and operations. Rushing to rebuild risks losing not features but implicit rules that no one can explain clearly yet are still in use. For example, a discount logic may have been decided by the sales director years ago and never documented.
Our first step is always "archaeology": map out the legacy system's core processes, data dictionary, and exception branches, and confirm them item by item with business departments. After this step, we often find that only one-third truly needs refactoring; the remaining two-thirds are just UI and interaction issues.
Three ways to slice incremental refactoring
The first is by module: split the system into finance, orders, inventory, and other modules, replacing one at a time, with old and new systems running in parallel during replacement and daily data reconciliation. The second is by user: let one branch or business line switch to the new system first, and roll it out after it runs smoothly. The third is by scenario: start with the highest-frequency, most painful operation entry point so users get an early win.
The three approaches can be combined, with one principle: at any moment, only one system in production carries core business; the switch window must be short, and rollback must be fast.
Data migration is the real challenge
In refactoring projects, code is often not the hardest part; data is. More than a decade of legacy data has dirty formats, duplicates, and mismatched primary keys; moving it directly will inevitably cause chaos.
Our approach is to conduct a data health check first: quantify duplication rates, null rates, and inconsistent coding, and confirm with the business which historical data can be cleaned and merged and which should only be archived, not migrated. We run three rehearsals before migration, each validating whether key report numbers match; if not, we investigate until all three are green before proceeding for real.
The core of incremental refactoring: do not interrupt the business
The biggest risk of a rebuild is business stoppage; the entire point of incremental refactoring is to avoid stoppage. The most complex legacy system transformation Shenzhen Dushi Technology has done involved eight subsystems and three years of gradual switching, with business never stopping for a single day. Legacy system transformation is slow work, but slowness is precisely to avoid major chaos.