A company replaces the application that processes payments from its business customers. The new implementation follows the documented requirements and passes its tests. During integration, a partner file is rejected because the old application accepted a format the specification never mentioned. Finance then identifies a quarter-end adjustment missing from the replacement.
The team has discovered requirements that were absent from its initial account of the system. Some may remain necessary; others may be workarounds the business can remove. Either way, the replacement needs an informed decision about what happens to them.
This explains part of the difficulty of legacy modernisation. The application being replaced exists within a working arrangement of data, integrations, business rules, and human knowledge. Understanding that arrangement can require as much attention as implementing the new software.
Investigating What the Existing System Does
Documentation, source code, tests, incident records, and conversations with operators all contribute evidence. None should automatically be treated as a complete specification. Documentation may describe intended behaviour, while the code and operational process reflect changes introduced over years of use.
For the payment application, the team might find unusual retry logic. It could compensate for a particular processor failure or simply survive from an earlier design. The next step is to investigate the conditions around it, including what downstream systems do when a request is repeated.
Existing behaviour should not be assumed correct because it has remained in production. Some defects are tolerated, hidden by manual checks, or encountered too rarely to have been noticed. The investigation needs to connect behaviour with a current requirement and an owner who can resolve uncertainty.
The replacement specification can then distinguish what is agreed, what is inferred, and what still needs examination. This helps the team proceed without turning every unexplained detail into either a permanent requirement or an accidental omission.
Finding Dependencies Outside the Application
The payment system may supply exports to Finance, files to partners, and status information to customer-facing services. Staff may query its database directly or use scripts written to resolve earlier operational problems.
Those dependencies affect the replacement even when they are absent from formal architecture diagrams. An export’s ordering or timestamp format may matter to a consumer that has adapted to it over time.
The Legacy Mimic pattern describes one way a new system can satisfy existing interactions during incremental replacement. Such compatibility can help sequence work without forcing every consumer to change at once.
For this company, preserving a partner file temporarily might allow the payment implementation to move first. The team can then agree a new interface and migrate the partner separately. The temporary arrangement needs an owner and removal conditions so that compatibility does not become another unexplained dependency.
Capturing Operational Knowledge
People contribute to the service in ways that source code cannot fully describe. An operator may know which batch must finish before a restart, while a Finance analyst may recognise a status that requires investigation rather than immediate correction.
The replacement team should observe those tasks and ask what they accomplish. Some may expose a missing application capability; others may be safeguards against a known failure. Recording the action without its purpose leaves future operators with instructions they cannot confidently adapt.
Recovery exercises can help turn individual knowledge into shared evidence. Another team member can attempt the procedure using the available documentation, identifying missing credentials, unclear steps, or assumptions about system state.
This work benefits the current service too. Modernisation may take time, and staff can leave before the replacement is ready. Reducing reliance on individual memory gives the organisation more room to investigate and change the system deliberately.
Comparing the Risks of Keeping and Replacing
The existing application has encountered real workloads and operating conditions. That history provides evidence about its behaviour, but it does not guarantee future reliability or establish that its risks remain acceptable.
Continuing to operate it may involve unsupported dependencies, difficult staffing, or uncertain recovery. Replacing it introduces migration, integration, and learning costs. A credible comparison needs both sets of risks and the consequences for the business.
Support status should be checked for the actual components and arrangements involved. Microsoft’s end-of-support guidance, for example, explains the loss of ordinary updates and assisted support, while noting that paid programmes may be available for some products. A generic description of a system as old is insufficient to establish its support options.
For the payment service, leadership needs to understand what makes continued operation harder and what the proposed replacement would improve. That creates a more useful investment decision than comparing programming languages or assuming a cleaner architecture will necessarily cost less to operate.
Building Evidence About Behaviour
Characterisation tests capture observed behaviour when the team does not yet have a complete account of what the code does. They can help identify changes during later work, but passing them does not establish that every recorded result is desirable.
The payment team can combine such tests with approved business examples. Historical inputs may reveal differences between implementations, while domain specialists establish which results should be preserved. Test data needs appropriate handling, and replay must avoid producing real charges or other unintended effects.
A mismatch should lead to a decision. The replacement may contain an error, the old application may contain a defect, or the business may want a new rule. Recording the explanation prevents an intentional change from being confused with an unexamined divergence.
Functional comparisons also need operational checks. The application must handle relevant volumes, expose useful failure information, and support recovery. A correct payment calculation is insufficient if staff cannot determine which transactions completed after an interruption.
Moving Responsibility in Manageable Parts
The team may be able to move a defined payment type or customer group before replacing the entire application. Incremental replacement can limit how much unproven behaviour receives production responsibility at once.
The boundary must be workable. The team needs to establish which system accepts updates, how related records remain consistent, and what happens when an operation crosses between old and new. Additional adapters or duplicated state create operating work that belongs in the plan.
Rollback needs the same precision. If the replacement has processed new transactions, returning to the old application may require reconciliation or state transfer. The transformation plan should establish when that remains possible and who can authorise the response.
Some constraints may be addressed without replacing the whole application. A supported runtime, improved recovery process, or a stable interface around existing logic can provide value while reducing the scope of behavioural change.
Measuring Whether the Constraint Was Removed
The company should return to the reason for modernisation when assessing the result. If the objective was easier partner integration, measure the effort and time required for a new connection. If it was recoverability, exercise recovery under relevant conditions. If it was supportability, confirm that the operating team can maintain the resulting environment.
Where replacement is intended, retirement remains part of the work. Unusual payment types, historical queries, or manual corrections may keep the old application necessary after most transactions have moved. Each remaining dependency needs a decision before shutdown.
The old system’s history is useful evidence for this process, alongside current requirements and operational testing. The team can preserve necessary behaviour, change contracts deliberately, and remove workarounds once their purpose has ended.
For the payment company, successful modernisation means it can process the required transactions with a more supportable service and a clear account of its behaviour. The new implementation matters because it enables that outcome and leaves the organisation better prepared for the next change.
