I used to think of a system transition principally as a movement between environments. The work had to arrive intact, the application had to function and the users needed a supported route into the new arrangement. Those remain substantial responsibilities. In manufacturing and laboratory work, however, they do not exhaust the question. A record can arrive in the new environment while part of the explanation needed to interpret it remains behind. The technical move may be finished before the organisation has preserved what it needs to understand its own earlier decisions.
That is why I now begin a record-continuity discussion with a reader rather than a transfer mechanism. I imagine a qualified colleague returning to the material after the original team has dispersed. The person may need to know which method was used, what version applied and how a later change relates to the first entry. A visible result is useful, but it may not supply the whole account. I cannot decide every interpretive requirement myself. My task is to bring the relevant specialists into the design before the project has committed to a route that preserves only what was easiest to move.
Begin with the future reader
The phrase future reader can sound abstract until it becomes a practical exercise. We ask a colleague with the appropriate knowledge to find and explain a controlled package using the proposed arrangement. We observe which dependencies the person needs, where the route is unclear and what remains available only through the original environment. This does not turn one exercise into proof of universal suitability. It gives the project a concrete account of an intended use, against which technical choices can be examined. The scope and limitations of the exercise are part of its value.
In fourteen instrument-system restoration exercises, all the associated backup jobs had reported success. Eleven restored packages supplied the context required by the agreed exercise. Three did not provide the necessary method-version context through the restored environment. The backup result and the interpretation result were both real; they answered different questions. We could have presented the first as the more reassuring account. Instead, we preserved the original sources and funded further work. Nothing in that account establishes that a production record had been lost. It shows that our readiness claim needed to be narrower than our first report suggested.
The question of authority matters here. Technology colleagues can explain what was copied, restored and made accessible. Laboratory and quality colleagues determine what the material means for the intended review and what further examination is required. Good collaboration does not dissolve those distinctions. If I sign a technical completion note, it should be clear which proposition my signature supports. The organisation is better served by several compatible, bounded judgements than by a single broad statement whose apparent confidence conceals uncertainty about who has actually assessed it.
Test meaning as well as movement
A project needs observable criteria, but the criteria should follow the purpose. A count of transferred objects can establish that the expected number arrived. It cannot by itself show that an authorised reviewer can interpret them. A checksum may support a claim about unchanged bytes without settling whether a dependent reader or configuration remains usable. These checks can be valuable without becoming substitutes for one another. I want the transition proposal to identify the claim supported by each test and to say where another kind of evidence is required.
The same discipline applies to exceptions. If a small number of packages need an older reader, they should remain visible as a dependency rather than disappear into an overall completion percentage. That does not mean every exception blocks every stage of a programme. It means the relevant owners must understand what is being deferred, how it will be supported and what conditions would permit the next decision. A staged transition can be sensible. Its usefulness depends on whether the remaining obligations have actual owners, resources and review dates, rather than merely a place on a project list.
There is also a temptation to improve the historical account while moving it. A blank reason or an awkwardly documented change may look like something the new system should tidy. I distinguish a clearer way to display existing material from an attempt to manufacture an explanation that was never recorded. Where clarification is sought, its source and timing should remain apparent. The desire for a neat migration result should not make the later reader less able to distinguish the original record from subsequent interpretation. Technology can preserve that distinction or quietly erase it.
Our improvement programme for the restoration exercises cost EUR1.4 million over twelve weeks. I include that amount because record continuity is not achieved by declaring it important. It needs engineering work, specialist attention and an operating arrangement that can continue after the programme closes. The expenditure also has an opportunity cost. Other work may wait. A decision maker should be able to challenge both the proposed capability and the route chosen to provide it. Describing the issue precisely is more useful than suggesting that any expenditure carrying the word assurance must be accepted.
Give retirement a separate decision
A new application can be ready for incoming work while an old one remains necessary for earlier material. Those events should not be forced into the same date for the convenience of a project plan. I ask the retirement proposal to state which dependencies will end, which will continue elsewhere and what evidence supports that conclusion. If an older reader remains necessary, its ownership, access and support require a deliberate arrangement. Leaving it running unnoticed is not a continuity strategy, but removing it solely to achieve a planned saving is not a considered retirement either.
The eventual answer may be a better interpretation route, a controlled retained capability or another solution developed with the relevant experts. I would not impose a universal retention period or declare one architecture appropriate for every record. The decision follows the material, its use and the responsibilities of the organisation. What I can insist on as CIO is that the proposal does not confuse the end of a software project with the end of a business dependency. That distinction gives colleagues a more honest basis for discussing the cost and timing of change.
I want a successor to inherit an understandable account of what we did, including the unresolved parts. The people who produced the original record will not always be available, and the technology will continue to move. A durable explanation helps the next team avoid repeating an assumption simply because it was once embedded in an application. For me, that is the practical ambition of record stewardship: to leave the organisation able to examine its earlier work without relying on the memory of the person who last knew how the screen behaved.