Begin with the business capability
Legacy software is often described as a technical problem, but the real difficulty is operational. A system may contain valuable business rules, depend on undocumented processes and support work that cannot stop. Rewriting it all can replace visible limitations with new, less understood risks.
Do not start by asking which technology should replace the current stack. Start by asking what the system enables, who depends on it and what failure would interrupt. Map critical journeys, data, integrations, manual workarounds, support knowledge and contractual obligations.
A useful assessment separates four questions:
- Does the capability still create value?
- Is the current system dependable and supportable?
- What change is the business actually trying to achieve?
- Which dependencies make change difficult?
This prevents a common mistake: modernising components that are old but stable while ignoring the handoffs that cause delays and errors.
Choose a path per workload
Microsoft's Cloud Adoption Framework describes several migration strategies, including retain, retire, rehost, replatform, refactor, rearchitect, rebuild and replace. The value of the model is not the labels. It is the permission to make different decisions for different parts of the estate.
- Retain a stable system when change has little near-term value.
- Stabilise when reliability, security or recoverability must improve before larger work.
- Integrate when the core system works but data and workflows are trapped.
- Replatform to reduce infrastructure overhead with limited code change.
- Refactor where technical debt blocks maintainability or performance.
- Replace when a suitable product meets the need with acceptable compromise.
- Rebuild only when distinctive requirements justify the cost and risk.
- Retire capabilities that no longer deserve operational attention.
Modernise through seams
A seam is a boundary where behaviour or data can be separated safely. It might be an API around customer records, an event emitted when an order changes or a new interface for one operational team. Good seams allow incremental replacement without duplicating the entire system.
Prioritise slices that are independently testable and operationally useful. A first phase could expose reliable data, remove a fragile manual handoff or move a high-change module behind a stable interface. Keep the original process available until the new path has proved itself under real load.
Treat data migration as a product
Data work is rarely a final technical step. Define ownership, quality rules, reconciliation and cutover evidence early. Decide how historical records will be accessed, which system is authoritative during transition and how discrepancies will be resolved.
Parallel running may reduce risk but increases operational complexity. A direct cutover is simpler but demands stronger rehearsals and rollback preparation. The right choice depends on consequence, volume and the organisation's tolerance for temporary duplication.
Make the economics visible
Compare options across several years. Include licences, hosting, support effort, change lead time, incident impact, migration work and the cost of keeping specialist knowledge. A cheap migration that preserves every operating constraint may deliver little value. A full rewrite may consume capital before users see improvement.
Set outcome measures for each phase: reduced processing time, fewer reconciliation errors, faster releases, improved recovery or lower support effort. Stop or change direction when the evidence does not support the plan.
Modernisation works best as controlled portfolio change, not a single technology project.
Algoza helps organisations map complex systems, identify safe seams and sequence modernisation around measurable operating outcomes.