Migration risk is not stored in the source code, and the age of a system says almost nothing about whether it can safely be moved. What decides the outcome is the distance between what the running application reaches for and what the people who now own it can still describe, together with the terms on which the organisation is permitted to move it at all.
A policy administration system examined during one migration carried an application register listing three integrations. A fortnight of run-time observation found eleven. Four were file drops written by a contractor who had left years earlier, and one was a scheduled job that fired only at quarter end. No one had been careless. The register listed what people believed the system did, and the footprint listed what it did.
The gap between those two records is the thing to look for.
Three records decide whether a legacy application can move
Three candidates exist for the truth about a legacy application, and they are not interchangeable. The source record is the code and the documentation held with it: the repository, the interface specifications, the data dictionary, the change history. The run-time footprint is what the application actually touches when it executes: the calls, files, queues, scheduled jobs, credentials and data stores it depends on at the moment of running. The contractual status consists of the licences, support windows, exit terms and supplier arrangements that govern what you may lawfully and practically do with the software, and how quickly.
Only the first is easy to obtain. The next step determines the cutover plan. The third decides the budget, and occasionally whether the project is permitted to proceed at all.
What each record establishes on its own
The source record establishes structure and complexity. It shows where the logic sits, how tangled the control flow is, which modules nothing calls, whether any automated tests exist, and how much effort a code change will take. The run-time footprint establishes blast radius. It shows what breaks when this application breaks, which systems break when its interface changes, and where data exits the estate and where it goes. The contract establishes permission and price. It shows whether the licence survives a change of hosting, whether support expires mid-programme, and whether the supplier has any commercial incentive to release you.
The Government Digital Service guidance on managing legacy technology is blunt about where the difficulty sits. Organisations may find it hard to discover how their infrastructure has evolved and hard to disaggregate dependencies away from old technology without interrupting service, so they should build a complete register of data assets and establish the full extent of their systems because the documentation is frequently incomplete. That is the footprint argument, made by people who have to run the estate. The same guidance catalogues commercial decisions and spending models, contractual arrangements and exit strategies, and the use of multiple suppliers among the non-technical blockers that prevent migrations from finishing. The contractual status is listed as a blocker with the power to stop a project.
How fast each record goes stale
The source record decays one release at a time. Every change made without updating the interface specification or the data dictionary moves it further from the truth, and the drift stays invisible until somebody relies on it. The run-time footprint decays faster, because it changes the moment a new scheduled job or hand-built adapter appears, and those appear without programme approval. The contractual status changes on calendar events: renewal dates, end-of-support announcements, acquisitions of the supplier, and changes to the licensing model.
The practical consequence is that the source record is the slowest to mislead and the easiest to check, the footprint is the fastest to mislead and the hardest to check, and the contract is the likeliest to surprise a board that believed it had already dealt with the matter.
Questions the source record cannot answer
The source record cannot tell you who depends on the application. It can show an interface, and it cannot show the finance team that reconciles against it every Friday. The run-time footprint cannot tell you what the business means by the system, which is why a complete dependency map can still miss the reason a process exists. The contractual status cannot tell you whether parity is achievable, and no licence term has ever guaranteed that the same inputs will produce the same outputs under production load.
That last distinction matters more than it looks. The Glorium Technologies guide to legacy application migration sets out that data migration moves records between data stores and is judged on completeness and accuracy, while application migration moves running business logic and is judged on whether the same inputs still produce the same outputs. Two tests, two owners, one cutover date.
Cost of obtaining each record
The source record is the cheapest, because the engineers are already employed and static analysis does much of the work. The run-time footprint costs the most elapsed time, because it has to be observed across a full business cycle; month-end jobs, quarter-end jobs and annual processes do not appear in a two-week window. The contractual status costs procurement and legal attention, and it is the one most often delayed until a decision has already been made.
Four attributes that separate the three records
| Attribute | Source record | Run-time footprint | Contractual position |
|---|---|---|---|
| Unit inspected | Code, documentation, change history | Calls, files, jobs, queues, credentials, data stores | Licences, support, exit terms, supplier obligations |
| What it proves | Structure, complexity, test coverage | True dependency set and blast radius | What is permitted, by when, at what cost |
| How fast it decays | One undocumented release at a time | Immediately, with each new integration | At renewals, announcements and acquisitions |
| What it cannot show | Who relies on the system | Why the business relies on it | Whether parity is achievable |
When the records disagree, believe the footprint
The rule is short. Where the register and the footprint disagree, believe the footprint. Where the footprint and the contract disagree, pause, because the contract has a veto. Where the contract and the business case disagree, the business case is usually wrong about the timescale.
The commercial warnings, and where they land
The vFunction analysis of lift-and-shift fallacies makes the commercial version of the same point. It warns that licences valid on site may not be valid in the cloud, and that moving a monolith without addressing its technical debt relocates the debt and keeps it outstanding. The article quotes a technical debt report on what that debt costs:
Poor management of tech debt hamstrings companies' ability to compete. The complications created by old and outdated systems can make integrating new products and capabilities prohibitively costly.
That sentence is in the authorisation paper, where the board will read it.
Supplier claims worth testing at handover
Transputec provides a view of the same discipline from the delivery side of UK estate work. The source system stays live while the target is validated, reconciliation between the two runs continuously, and cutover happens only once reconciliation has been clean for an agreed period. If it has not been clean, the source stays primary and the date moves. Documented runbooks and architecture decision records go across at handover. Read that as a specification for a supplier, and it doubles as a specification for the application itself: where reconciliation cannot be made to run, cutover cannot be made to happen.
Tracing a line from the map to the date
The three files fix the questions in the way they must be answered. The footprint sets the timing of cutovers, because a dependency discovered late moves a date. The contract sets the outer limit, because it decides which routes are open at all. The source record sets the effort inside each step, and it is the only one of the three that can be improved while the programme runs: documentation written now, tests added now, and dead modules removed now all reduce the cost of whatever route is finally chosen.
A migration plan is successful if a reader can trace a single line from an entry in the dependency map to the party in charge, a documented interface, a licence that permits the move, and a date. A plan that cannot do that has not yet found the gap between what the register says and what the estate does.