Older software may need a focused improvement, not a rebuild. Start with the business problem: slow orders, fragile releases or inaccessible data.
Rebuild when the core design blocks necessary change and the benefits justify migration costs.
Compare your starting points
| What you discover | Improve or modernise | Consider a rebuild |
|---|---|---|
| Core behaviour | The system works; specific areas cause friction. | The core model no longer fits the business. |
| Changeability | Components can improve incrementally. | Essential changes affect the entire system. |
| Continuity | Operations require a gradual transition. | A replacement has a credible migration plan. |
| Knowledge | Existing business rules can be recovered. | Requirements can be validated with real users. |
| Evidence | Assessment identifies worthwhile, bounded improvements. | Replacement benefits justify the transition cost. |
Find the actual bottleneck
A dated order-management system may be held back by one unreliable warehouse integration. Replacing every screen may leave that problem untouched.
Review code, data and releases with the people operating the system. Compare targeted fixes, phased replacement and a rebuild.
- Map critical journeys, dependencies and ownership.
- Identify unsupported components and recurring failures.
- Confirm source-code access and recoverable backups.
Plan for continuity
A phased migration replaces one capability at a time. Budget for temporary connections between old and new systems.
Decide how records will be cleaned, transferred and checked. Plan for work in progress and a rollback if the release fails.
Compare the full cost
Include development, parallel running, user training, rebuilt integrations and transition support. Preserve business rules hidden in the existing system.
Judge success through real work: completed journeys, reconciled records and reliable releases. Start with the change that removes your biggest constraint.
Bring these questions to your brief
- Which business activity is most affected?
- What must stay operational?
- Who understands the data and hidden rules?
- How will you verify improvement?