A platform reaches the end of vendor support, but the application still calculates charges, reconciles accounts, and produces files that other organisations expect. The replacement project has a clearer architecture and newer tools. It has not yet demonstrated that it handles the business’s unusual cases correctly.
That gap helps explain why a system can outlive its original platform. The business depends on a capability whose behaviour is spread across application code, data, schedules, integrations, and operational practice. Replacing the technical environment means deciding which parts of that behaviour need to survive and how to verify them.
Continued use is not proof that the platform remains safe, nor that every old rule is valuable. It is evidence of dependency. A sound modernisation plan examines that dependency while addressing the risks of remaining on technology that is becoming harder to support and recover.
Separate the Capability From the Machinery
A billing capability can remain necessary across several generations of databases and operating systems. Its technical implementation may change while customers still need accurate invoices, finance still needs reconciliation, and partner systems still expect an agreed export format.
Describe that capability through its inputs, decisions, outputs, timing, and failure handling. This is more useful than beginning with a list of screens to recreate. An application can look familiar while calculating a different amount or missing a file-delivery deadline that another system depends on.
The original platform may supply behaviour the application takes for granted. Transaction boundaries, collation, decimal arithmetic, time handling, and job scheduling can influence outcomes. A migration should identify those dependencies rather than assume that equivalent-looking code has equivalent behaviour on the new runtime.
This is the focus of modernising a runtime without rewriting business logic: determine which contracts need preserving and which platform responsibilities need an explicit replacement. The right migration boundary depends on the system, rather than its age alone.
Recover Knowledge From More Than Source Code
An unusual branch in the code might implement a valid customer exception, an obsolete workaround, or a defect that users have learned to compensate for. Its existence does not establish which interpretation is correct. Investigate the surrounding evidence and identify who can decide the intended future behaviour.
Operational procedures often complete the system. A team may review rejected records each morning, change a parameter before a monthly close, or delay a job until a partner file arrives. Removing the old executable without replacing that work can remove a necessary control that was never represented in the application design.
Historical data provides another source. A record may contain a status that new creation paths no longer produce but existing calculations still support. A clean test fixture containing only today’s valid records can miss the states the replacement must read during transition.
Interview staff, inspect incident records and change history, and trace representative workflows end to end. Use these sources to develop testable claims with dates and scope. Where the reason for a rule cannot be recovered, record the uncertainty instead of inventing a reassuring explanation.
| Evidence source | What it may reveal | What still needs checking |
|---|---|---|
| Versioned code | Implemented branches and transformations | Deployment and reachable paths |
| Operational procedure | Human checks and recovery steps | Whether the procedure is still followed |
| Historical records | States and outcomes that exist | Meaning, completeness, and provenance |
| Partner contract | Required formats and timing | Current agreement and exception handling |
| Staff account | Intent and practical workarounds | Corroboration and continuing relevance |
Knowledge recovery with RAG can help locate and connect this material. Generated explanations still need source references and verification; they do not convert missing history into established requirements.
Treat Unsupported Operation as a Managed Risk
An application can continue functioning after support ends while its risk profile changes. Security fixes may stop, compatible hardware may become scarce, and recovery may depend on installers or expertise that are no longer readily available. An uneventful recent period does not test every one of those risks.
The Canadian Centre for Cyber Security’s guidance on obsolete products recommends transitioning away from unsupported products and describes security and operational concerns. That guidance should inform the risk assessment rather than becoming a blanket claim that every old application has the same exposure.
Identify the actual unsupported components, their network reachability, privileged access, dependencies, and recovery requirements. An isolated batch processor and an internet-facing service may need different priorities and interim controls. Verify any extended-support arrangement instead of assuming that the label legacy means no support exists.
Give continued operation an accountable owner, a defined review point, and funded transition work. Segmentation, restricted access, and tested backups can reduce some risks during migration. They do not create missing vendor fixes or justify an indefinite exception without reassessment.
Decide What to Preserve and What to Change
The old application’s outputs are useful reference evidence, but they are not automatically the correct specification. A replacement may intentionally correct an established error or implement a new policy. That difference needs an explicit decision and acceptance criteria so comparison testing can distinguish improvement from regression.
Separate technical migration from business change where doing so makes verification easier. Moving execution while preserving calculations poses a different question from redesigning the calculation, workflow, and data model together. Combining changes can be justified, but it increases the work needed to explain any difference.
Create examples around consequential boundaries: rounding, effective dates, invalid inputs, late records, and historic exceptions. Include ordinary high-volume cases and rare high-impact ones. The test set should reflect the capability’s risk, not simply the easiest records to extract.
For every deliberate difference, record who approved it, when it takes effect, and how historical results remain interpretable. Customers and operators need to know whether a changed figure is a new policy, a correction, or an unintended migration defect.
Keep unresolved decisions visible in the migration plan. A missing explanation for an old exception may block one part of the capability while other parts can proceed. Assign an owner and a consequence to that uncertainty, rather than allowing a generated specification or implementation deadline to turn an assumption into an approved requirement.
Compare Implementations Without Duplicating Effects
Parallel comparison can reveal cases the requirements missed. Run the same suitably controlled inputs through both implementations and compare the properties expected to agree. This may include amounts, status transitions, generated files, or decisions at an agreed point in processing.
Control the external effects. Two billing implementations must not both send invoices or collect payments simply because both are being compared. A candidate can calculate a proposed result without becoming authoritative, provided its access and output destinations enforce that separation.
Raw output equality may be too strict or too weak. Generated identifiers and timestamps can differ legitimately, while identical totals can conceal offsetting record-level errors. Define comparisons at the level needed to detect meaningful differences, then investigate mismatches individually or by a justified category.
The old system also needs a known version and configuration during comparison. If both sides change without a record, the result becomes difficult to interpret. Retain the input scope, versions, expected differences, and reviewer conclusions so the evidence can support the cutover decision.
Move Authority in Bounded Steps Where Practical
Microsoft’s Strangler Fig pattern describes replacing parts of a legacy application incrementally. This can make the transition more manageable when functionality can be routed through suitable boundaries. It is not a guarantee that every system can be divided cheaply or without shared-state complications.
A reporting function may be moved before the transaction writer, or a product group may transition while another remains on the original path. Define which implementation owns each operation and how data moves between them. Avoid allowing both to update the same business state without a clear conflict and recovery design.
Transitional adapters have an operating cost. They need monitoring, testing, and a retirement condition; otherwise the migration can leave both platforms and a permanent bridge. Include that temporary architecture in the delivery plan rather than treating it as invisible scaffolding.
Cutover requires more than routing new requests. Account for in-flight work, scheduled jobs, external references, user permissions, and rollback or reconciliation. A replacement can handle new records correctly while failing to resume obligations that began on the old system.
Make Retirement a Verifiable Outcome
Before shutdown, establish that no required consumer still depends on an old API, file share, schedule, or report. Observation helps, but a quiet week may miss a quarterly process. Combine runtime evidence with owner confirmation and the relevant business calendar.
Retain historical information in a form that can still be interpreted and accessed under the required controls. Keeping a database file is insufficient if reading it requires a retired runtime, missing keys, or undocumented code values. Test retrieval of representative historical records before removing the old environment.
The capability should emerge with clearer ownership, reproducible checks, and a supported operating path. That preserves what the business needs without treating the old implementation as untouchable. A successful migration reduces both uncertainty about behaviour and dependence on the platform being retired.
