Reviewed and updated October 8, 2026.
Start with the system’s consequences: Measure the work and cost a legacy system creates, the responsibilities it carries and the risks of changing it. Use that record to decide whether to maintain, integrate or replace it.
Build a current operating baseline
- Direct costs: Record licenses, infrastructure, support contracts, specialist maintenance and the staff time required to operate the system.
- Work around the system: Document manual exports, duplicate entry, reconciliation, approval delays and recovery work. Measure actual frequency and time spent.
- Reliability: Review incidents, their business effect, recovery steps and unresolved causes. Distinguish recorded losses from estimates.
- Dependencies: Map interfaces, data ownership, access rules and the people who understand the system. Identify which business processes rely on each connection.
- Capacity and change: Test the workload and changes the business expects. Record the constraints observed in that environment.
Compare the available paths
Compare continued maintenance, a targeted repair, an integration layer and replacement against the same requirements. Include migration, parallel operation, data cleanup, training and the work needed to retire the old system. Identify licensing and supplier constraints before treating any path as feasible.
Keep the model auditable
Link each cost and benefit to its source. Label assumptions, show uncertainty and test whether the decision changes when an important input moves. Separate potential new revenue from observed revenue loss and from time saved.
Repair, integrate or replace worksheet
| Path | Question to resolve | Record to request |
|---|---|---|
| Maintain or repair | Can a bounded change remove the observed constraint? | Incident causes, repair scope and acceptance test |
| Integrate | Can information move reliably without replacing the system? | Interface contract, access rules and reconciliation cases |
| Replace | Will the new system meet the requirements through migration? | Migration rehearsal, parallel-run checks and rollback conditions |
Record cost ranges and dependencies for each feasible path. A system being old does not by itself establish that replacement will save money.
Plan the change around business continuity
Define acceptance tests, the rollback plan, migration checks and the people responsible for operation after each phase. Start with a bounded system or workflow where the team can evaluate the result while preserving the required service.
Related implementation evidence
The rebuild-or-tune analysis discusses a stalled AI system and the limits of that engagement. The business-case evidence review explains how inputs were checked and assumptions separated. The production voice-platform operating report sets out the operating records and recommended handoff practices to consider.
For delivery scope, see AI system integration and custom AI development. Request a project review to discuss the system and the decision in front of you.
