Why is extending an inherited system risky, and when should it be rebuilt?
Choose extension or replacement through technical due diligence, not system age or an arbitrary “60% change” rule. Wavesteam first verifies lawful access to source and dependencies, reproducible build and deployment, protected data, and regression evidence for critical business work. Retain stable assets and replace unverifiable cores progressively. A full rewrite is among the riskiest options because undocumented rules may disappear with the old code.
The risk is unknown dependency, not unattractive code alone. A new team may not know whether behavior is a rule, historical patch, or accidental defect. Reports and external consumers may rely on undocumented fields. Repositories, SDK accounts, certificates, and cloud assets may not belong to the client. Without regression tests, impact is not measurable. Record existing defects, version, and environment at takeover so later responsibility can be distinguished.
When comparing platform capabilities, constraints, and switching costs, also compare What should be assessed before rebuilding a slow, insecure on-premises system in the cloud? and Can an app and a mini-program be built together, and does that double the price?; the linked guidance adds context that should be considered in the same decision.
| Route | Evidence that supports it | Main risk | First proof |
|---|---|---|---|
| Maintain and extend locally | Reproducible build, stable core, bounded change | Technical debt constrains later work | Representative change and regression in isolation |
| Wrap old core, build around it | Rules are hard to replace but interface is stable | Complex data and failure boundary | Contract, observation, rollback |
| Progressive module replacement | Modules can separate; business cannot stop | Dual systems and migration reconciliation | Low-coupling independently accepted first module |
| Full rebuild | Assets unusable or unlicensed; core model unfit; cutover affordable | Hidden rules, migration, adoption failure | Real cases prove the new model covers old behavior |
Inventory repositories and branches, build chain, deployment, database, files, interfaces, domains, certificates, cloud, and supplier contracts, confirming ownership and access. Build and deploy from source in a clean controlled environment and record missing dependencies and secrets. Scan dependencies, vulnerabilities, and licences and create an SBOM. SPDX standardizes component and licence information, but distribution obligations still need human review.
Use production logs, user interviews, and sample data to identify critical tasks and add characterization tests around acceptable current behavior before changing it. Profile data quality, migration keys, consumers, performance, and security. NIST SSDF supplies secure development practices for the takeover, not a rebuild decision.
Duration follows size, access completeness, and risk. Deliverables include build proof, asset and dependency map, existing-defect baseline, core-flow tests, data profile, prioritized risk, work breakdown for alternative routes, and the first validation plan. If the production release cannot be tied to a source commit, pricing must include restoration of that baseline.
Even after a rebuild decision, treat the old system as business evidence. Sample real orders, permissions, reports, and exceptions and mark each for migration, archive, or retirement. Preserve read-only and audit access for the required period. Cut over by module or user group with reconciliation, write freeze, rollback, and data checkpoints. Dual write is appropriate only with explicit ordering, conflict resolution, and observation.
Compare lifecycle cost and risk: legacy change effort, incidents, security exposure, and staff availability against new build, migration, parallel operation, and training. Lines of code and feature percentages lack a common denominator; a small settlement core can dominate risk.
Wavesteam documents inherited defects, unknowns, and responsibility before acceptance. Extensions include regression, migration, and rollback evidence; replacements define traffic switch and exit per module. Client ownership of code, data, and accounts prevents Wavesteam from becoming another system that cannot later be taken over.