Decommissioning
Most legacy systems do not die. They are migrated and keep running: as a read-only copy, as a cost line, as an open finding in the audit report. We guide the retirement so that two things remain at the end: a system that is switched off, and evidence that holds without it.
A transformation does not pay off the day the new system goes live.It pays off the day you are allowed to switch the old one off.
Three things move only once you switch the legacy system off: the cost, the risk, and the people it ties up. The fourth decides whether you may switch it off: the evidence.
The savings your business case counts on arrive only here.
Once it stops running, nobody has to govern it anymore. After the end, named residual obligations remain and nothing else.
Your best people come off legacy maintenance and back into the business, and your budget with them.
The evidence outlives the system that produced it.
We do not quote percentages here. What a retirement saves is decided by your licensing model, your operating model, and the number of consumers still reading. We measure those first.
The retirement decision is yours to make, not ours. Our job is the evidence it rests on.
On that basis, the retirement decision can be made.
A recommendation to switch off is worth as much as the independence of whoever gives it. So here is what we are not, and what we do not do.
We earn nothing on your licenses. That is why we can also tell you which ones you do not need.
Your integrator builds it. We hold your side of the table while they do, including when the right answer is: do not migrate, archive.
No operating contract, no maintenance, no read-only copy on our invoice: we earn nothing on your operations. What the parallel operation costs belongs in your business case as a line of its own. We count those costs before we take them out.
We deliver the evidence for switching off, not a reason to extend a program. And we name the goal plainly: your independence, including from us.
The migration counts as finished, and the legacy system keeps running anyway. Four reasons almost always occur together.
Licenses, operations, maintenance, and support continue, although no business process runs on the system anymore. The business case for the migration counts on exactly these savings. They arrive only with the last teardown steps, long after the program has moved its attention elsewhere.
A system on its way out loses its care faster than it loses its reachability. It stays on the network while attention has long since moved to the target platform: security fixes are no longer applied, certificates lapse unnoticed, and monitoring rules describe an operation that no longer exists. Regulators and internal audit have no category for “half switched off.” A system on the network has to be governed for the whole time it is running.
Whoever understands the legacy system is needed for the legacy system: for the quarterly run, for the audit request, and for the one report nobody rebuilt. Those people are missing from the target operation. If they leave the organization, a system without an explanation remains.
Only those who can show that nobody depends on the system anymore, and that the records exist elsewhere in auditable form, may switch it off. Without that proof, keeping it running is the only responsible decision. Decommissioning is therefore a task of evidence, not a task of operations.
That is why we put the question of retirement at the start and not at the end.
Seven rules carry every retirement. They decide sequence, scope, and evidence before anyone talks about a tool. Five of them also carry one specific component of the Flying Bridge, noted underneath the rule.
Whatever is migrated has to be mapped, reconciled, and given a permanent place of its own in the target system. Each of those stages costs, and not only once. So the decision comes first, per data set: migrate, archive, or destroy once the retention period ends. Of those three answers, migration is the costliest, and it has to prove itself against the other two rather than the other way around.
For every data domain, meaning every set of records that belongs together in business terms such as customer master data or positions, exactly one system is the system of record at any point in time. Everyone involved can name it. Write access on the other side is blocked technically, not merely discouraged by procedure.
Carries: the write path of the Flying Bridge
Each plan states its point of no return: the step after which there is no way back. Everything ahead of that point needs a fallback that has actually been rehearsed, not one that has merely been written down. The legacy environment, the backups, and the reversal runs stay in place until that point is formally acknowledged.
Carries: the way back out of the Flying Bridge
A bridge, a temporary control, an intermediate store: each of these is given three things while it is still on the drawing board: an owner, covered running costs, and a date for its removal. Leave the date out and the component does not disappear; only its documentation does. What the next program then clears up is not the legacy system but the transition period ahead of it.
Carries: the end of the Flying Bridge
Measurement happens at every step: extract, mapping, staging, load run, and archive ingest. Anyone who compares only the beginning and the end cannot say, when something breaks, which step caused the loss. Reconciling per transition finds it while that step can still be repeated.
Carries: the reconciliation track of the Flying Bridge
The legacy system does not go from full operation straight to off. It keeps running write-locked for a defined period, and that period is when the quarterly close, the year-end processing, and the examination request turn up that no workshop found. Against a system still running, that costs days; against a dismantled one it costs a project of its own.
Carries: the exit from the Flying Bridge
Before a single irreversible step runs, the archive is complete, readable, and accepted. It is tested with checksums across the whole data set and with samples that have to be readable in business terms, not merely present in technical form. Readable here means: without the system that was switched off. If a data set needs precisely the application being dismantled in order to be understood, it has been stored rather than archived, and it will not answer a question in an examination.
Between the legacy system and the target system lies a phase in which both run. Flying Bridge is our name for that phase when it is designed rather than endured: a sequence of numbered transitional states with entry and exit criteria that can be tested. Each state can be operated and audited on its own. Each transition has a way back until the steering committee decides explicitly that from here on there is none.
The components are derived, not chosen freely. Write path, reconciliation track, and way back are each one of the rules above in built form. Read path and switch follow from the same rule as the write path: whoever settles which system is the system of record also has to settle who reads from it and when that status moves. The two remaining load-bearing rules govern no component but the end of the bridge and the exit from it; see the section below and step 07 of the sequence.
Where does the business event arise, and in which system is it recorded? Exactly one answer applies per domain and phase, enforced technically. The write path moves step by step, and every shift is a transition of its own. For keeping both sides in step, there is a ranking: one-way copy before continuous change capture before dual entry.
Derivation: The rule “a single system of record per domain” in built form.
Who reads what from which system? Reporting, regulatory feeds, and downstream consumers stay attached to the legacy world longer than the write path does. Every consumer is listed by name and moved over one at a time. An entry is closed by the consumer’s confirmation, not by the observation that nothing flows anymore.
Derivation: Follows from the same rule: naming a system of record achieves nothing while nobody knows who reads from which side.
At every transition we measure instead of assume: count, value, attribute, and the comparison against neighboring systems. Tolerances are fixed in advance and are not left to the judgment of whoever runs the job. Differences become cases with an owner and a deadline, not an email thread.
Derivation: The rule “reconcile at every transition” in built form.
The switchover has two positions and no gray area. A criterion names a measure, a threshold, and an observation period; “running stably” names none of those. Every switch comes with a rule agreed in writing beforehand: who wins when the two sides say different things. That rule is agreed before the transition, not negotiated during the incident.
Derivation: Follows from the same rule: the switch is the handover of system-of-record status itself, which is why it has exactly two positions.
For every transition, a rehearsed route back into the previous state: the legacy environment kept alive, source data secured, reversal runs tested, and a limited window in which bridges already switched off can be switched on again. This provision costs money and therefore appears as its own line in the business case.
Derivation: The rule “reversible up to a named point” in built form.
The states are numbered and described one by one. Each has to be habitable. If the program stops there because a budget stalls or an audit intervenes, the organization must be able to run in that state, complete a reporting period inside it, and be examined while sitting in it. States that are safe only while you cross them quickly are not architecture.
A transition either has a defined way back, or it is a named point of no return that the steering committee acknowledges. We do not allow a third case. Without a way back, a team no longer has a choice, only a direction, and so it keeps a broken cutover moving.
Every temporary component is registered when it is created, with its purpose stated as an ending condition, an owner, running costs, and a teardown date. The steering committee sees three figures: open entries, running costs, and the number of entries past their teardown date. The third has a target value of zero. Tearing down the bridges of one state is an entry criterion for the next, and an extension is a named decision rather than a quiet slip of a deadline.
The opening balance roll-forward, a closing-to-opening reconciliation, is the auditable proof that the closing balance of the legacy system carries forward into the opening balance of the target system, position by position, with every difference explained and signed off. It is the one place in the program where data migration and financial accounting look at the same figure and agree on how it comes about. It is not a reconciliation run. It is an accounting document, and it is signed.
A tolerance is a decision, not a computed quantity. It is made before the first run, it lives in the configuration, and it carries a name: that of its approver. Three cases, and they differ not by type of data but by how much latitude is admissible at all.
A tolerance that names neither its approver nor its reason was never agreed on; it was overlooked. It has to be corrected before the first run, not defended when an auditor asks about it.
The roll-forward is a document with signatures, not a job result. It is signed once and then sits in the evidence file.
The roll-forward is retained for as long as the longest retention period of the records it explains. For German institutions, that is normally the ten-year period for books, inventories, and financial statements under Section 147(3) of the German Fiscal Code (AO). Accounting vouchers now have to be kept for eight years under that provision, with transitional rules for supervised institutions (as of October 2026 · not legal advice).
Reconciliation and the opening balance roll-forward look at the same data and answer different questions. Reconciliation asks whether everything arrived; the roll-forward asks whether the opening balance is right, complete, and derivable. Reconciliation runs again and again, along three axes and with a fourth comparison that is left out most often.
Counting runs along the processing chain and per segment: extract, staging, load run, rejects, and quarantine. Totals across the whole hide offsetting errors, so the chain is cut into pieces. Every deviation needs an explanation, and in the comparison of records that explanation is a business category and not a technical reject reason.
Comparison runs per currency, booking entity, and general ledger account. On general ledger balances the tolerance is zero. The point of comparison is fixed in the run plan, because most apparent differences are artifacts of timing and not data errors.
Comparison runs over a checksum per row across the mapped fields. That finds swapped fields, truncated content, character set damage, shifted dates, and silent defaults. It does not find whether the target system interprets the same field differently. A field can match on the checksum and still be wrong in business terms, because what is transferred is meaning and not only content.
Reconciliation runs against the neighboring systems that have to agree with the result: customer records, instrument master data, mandates, and risk and finance data stores. This comparison is left out most often and then fills the incident list of the first weeks after the cutover.
Every difference outside tolerance is classified, and the classification decides what happens next.
A processing state, or a position in run-off. It carries an expected clearing date. If that date passes repeatedly, the classification loses its justification: the difference is classified anew and pursued like a defect. No category is misused more often than this one.
Brought about deliberately. Becomes an adjustment position in the opening balance roll-forward, with a rationale and an approver.
A mapping or load error. Correct it, then run a clean repeat.
Immaterial, with written acceptance by the data owner.
A flaw already known in the legacy system. It is loaded as an expected difference in advance, so that the first production run tells new problems from inherited ones by itself.
The only status that blocks a gate.
Every difference is given a named handler when it arises; unassigned differences raise an alert automatically instead of aging in a list. If a difference recurs across several runs, it counts as systematic regardless of its size and is traced to its cause. It is closed by a clean repeat run or by a complete letter of acceptance, in both cases reviewed by a second person.
Eight steps in a fixed order. Skipping one only moves it: into the stabilization phase, into the annual audit, or into a follow-up program.
Before anything moves, we ask whether migration is needed at all. One line per data set: migrate, archive, or destroy once the retention period ends, with a retention period and an owner. This step determines the size of everything that follows.
Big-bang cutover, waves, or archive and start fresh. Derived from the number of interfaces, the volume profile, the entity structure, the closing and regulatory calendar, and the maturity of the target platform. The decision costs a few workshops and one architecture approval. Reversing it after construction has started costs quarters.
If the analysis points to waves, the time in between is designed rather than endured: numbered states with testable criteria, a system-of-record rule per domain and phase, bridges with an end date and running costs, temporary controls across the seam, and a way back for every transition.
Count, value, attribute, and the comparison against neighboring systems, at every transition and on a fixed rhythm. Tolerances set in advance, differences with an owner and a deadline, and evidence that is system-generated and filed unaltered. Without this measurement, the bridge rests on trust.
The measurements become a document that can be signed: legacy balance, movements, adjustments, and new balance, per booking entity and currency. Here the result changes level, from processing into the balance sheet, and it acquires signatures.
With the roll-forward signed off, the target platform becomes the system of record for every domain in scope. The point of no return is set deliberately and acknowledged formally, not reached by the passage of time. Only after that does the first teardown step run.
Consumers moved over one at a time and confirmed in writing, silence in the traffic logs across an observation period long enough to contain a month-end close, shutdown with a limited window for switching back on. The legacy system is then write-locked, the user group reduced to a named list and every query logged. That log is the requirements specification for archive access, written by reality instead of by a survey.
The final extract runs against the source while it is still alive, including audit trails and the lookup tables without which the data would be unreadable years later. Only the signed archive test opens the irreversible steps. Then the order is disable, let it rest, and delete, each stage as an approved change with a fallback statement and with a verified state instead of a closed ticket. Destruction is a named decision with a data set, a legal basis, a method, and an approver, never a side effect of dismantling.
A retirement is complete only when it can still be explained without the system that was switched off. Five results do that.
System-generated, unaltered, time-stamped run results with a run identifier, the person who ran them, the environment, and the version of the comparison definition. The measure is reconstructability: an auditor has to be able to follow the result from the file alone. Screenshots are not evidence.
The derived opening balance per booking entity and currency, with adjustments, rationales, and approvers. It carries the retirement decision and the first financial statements after the cutover.
Which system was the system of record for which data domain on which date, derived from the state definitions of the transition period. That is the answer to the most frequent question in an examination.
Records in a form that stays readable without the retired application. Proven by checksums across the complete data set, by sample retrievals across the whole period in a form readable in business terms, and by a timed retrieval measured against supervisory expectation.
What the organization still owes after the end: read access for named roles with annual recertification, records under legal hold, operation of the archive, a recurring retrieval test, and destruction when the period expires. One owner, one cost line, one end date per entry. Then the certificate, and no interim states after it, because that is where records live without an owner.
A designed transition period is not always the right instrument. In six cases, we advise against it, and we say so before the engagement rather than after.
If no rule can be written for a domain stating which system is the system of record in which phase, two systems end up claiming that role. The bridge is then not a transition but a second book of record, with all the consequences for reconciliation, auditability, and answers to the regulator. The domain boundaries have to be settled first.
Without dependable change timestamps or a working change capture on the legacy side, the delta strategy is an assumption and not a technique. That has to be checked before the pattern is chosen, not hoped for during delivery.
Discontinued products, closed books, and pure lookup systems. Here the more honest and cheaper route is this: records into an auditable archive, new business started on the target platform, legacy system switched off. This option is rarely examined, because migration teams are set up to migrate. We put it on the table first.
One application, one booking entity, a manageable number of interfaces, a load run that fits into the night, and a target platform already proven elsewhere. In that case, the big-bang cutover is the lower-risk instrument, and a bridge would be effort without return.
A bridge costs money twice: once while it is being built, and then in every month it runs. If that line is missing from the business case, or cannot be carried, the benefit erodes from the inside while the program reports progress. Then the business case has to be corrected first.
Anyone who does not enforce end dates at the gate, and does not decide extensions by name, gets the most expensive option of all: two systems at the end instead of one, and the next program starts by cleaning up this one.
Advisory work without a limit is not advisory work. We name the limit before the proposal.
Next step
In a confidential conversation, we assess the situation: what really has to come along, what belongs in the archive, and which piece of evidence is missing today for the retirement decision.
45 minutes, by video, free of charge.
How ready is your decision? Check it in 3 minutes.
Call +49 6021 625 63 40
