Modernising legacy software: maintain, rebuild or replace?

Age alone is not a reason to replace software

A twelve-year-old application may process orders reliably, while a two-year-old one may already be hard to change. Modernisation becomes relevant when changes block new services, a platform loses support or essential processes depend on one person's knowledge. Established software also contains operational experience: special prices, correcting entries and unusual exceptions may exist only in its code. Rebuilding the interface and standard workflows alone can lose those rules.

Inventory each important application's processes, users, data, integrations and owners. Record the duration of recent changes, weekly manual transfers, supported versions and tested recovery paths. A monthly import needing two days of reconciliation because customer IDs differ across three systems may need a sound interface. An essential application on an unsupported operating system requires a different decision: platform migration, replacement or a time-limited bridge.

Choose the strategy that addresses the actual constraint

Strategies can differ by system and function. Microsoft distinguishes migration approaches and evaluates workloads together with their dependencies. Moving to the cloud is an infrastructure decision, not proof that the application itself has been modernised.

• Maintain and stabilise: suitable business functionality, supported components and little need for change; continue watching dependencies and eventual replacement.
• Rehost: change hosting or replace old hardware; the application structure and many operating problems remain.
• Replatform: move the runtime or database to a supported foundation while retaining core business logic; compatibility still needs testing.
• Targeted refactoring: improve bounded weaknesses that are changed frequently while leaving other functions running.
• Replace or retire: use a better-fitting standard product or remove an unnecessary function, after resolving migration, archives and dependent processes.

Replace gradually, with an end to parallel operation

In the Strangler Fig pattern, new components gradually take over bounded responsibilities and an intermediary routes requests to the appropriate application. Microsoft's guidance also describes transition costs, shared data and the intermediary becoming a bottleneck. The pattern does not suit every small system or one due for complete replacement shortly.

For example, separate the customer view from an established order system while quotations and invoices remain in the original application. Before the pilot, decide which system may update addresses and how changes propagate. Two independent write paths create contradictory records. A traceable data flow is a useful milestone; a new screen alone is not.

Every bridge needs a retirement condition. Otherwise the business pays for both platforms and their connection indefinitely. A pilot could require reconciliation of all active customers, adoption of the new view by the business team and confirmation that no production reader still needs the old interface.

Cost development, transition and operation together

Compare stabilised continued operation and the proposed modernisation over the same period. Include hosting, licences, support and expected change effort in both. Migration adds analysis, data cleansing, parallel operation, training and retirement. Present uncertain savings as ranges.

An illustrative calculation: ten hours of reconciliation actually avoided each month, at an internal rate of €70 per hour, gives €8,400 a year before extra operating and maintenance costs. Whether saved time becomes reduced expenditure or available capacity depends on the business. Assumed avoided outages are not guaranteed additional savings.

A data import is complete only after business reconciliation

Matching record counts do not prove a correct migration. Check customer IDs, totals, relationships, character encodings, time zones and historical exceptions. Assemble representative cases before rebuilding: a normal order, partial cancellation, credit note and retrospectively changed contact. Compare expected results in both systems and have the business resolve discrepancies.

Define how new writes are handled during cutover. Once production data has changed in the new application, simply restarting the old server may be insufficient. The return path needs reconciliation, an agreed time window or a predefined forward correction.

The first weeks should reduce uncertainty

A bounded discovery phase should produce a map of important data flows, supported platform versions and representative business cases. Interview users, operations and developers together. Infrequent activities such as year-end closing, reversals, exports and deputy access may not appear during a short observation window but can be critical.

Aim a small technical investigation at the largest unknown. Verify an uncertain export before building the new interface; establish access to a third-party integration early if it controls the schedule. A deadline and written result prevent analysis from continuing without a decision.

Give each milestone a benefit, acceptance criteria and a stop condition

Choose an end-to-end business process for the first milestone, such as showing existing orders to a limited user group. Acceptance names expected data, response time under agreed load, permission cases and the business reviewer. Errors and data differences must be observable before a wider release.

If repeated trial imports still produce unexplained differences, postpone production cutover and investigate. Money already spent is not evidence that the data is ready. After the milestone, decide whether to add the next function, adjust the strategy or keep the stable intermediate result.

Treat retirement as a separate work package

After cutover, nightly exports, accounts or reporting tools may still access the old database. Identify and migrate these readers and writers. Historical data must remain discoverable in an agreed usable format; an unreadable file dump is not a useful archive.

Close out old access, licences, backup jobs, alerts and operational documentation. Coordinate contract termination and the end of required access so retirement does not cause another interruption. Only then compare expected savings with actual operation and document remaining differences and their causes.