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 flank 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.
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 any more. 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, monitoring rules describe an operation that no longer exists. Supervisors 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, 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 any more, and that the holdings 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 holding: 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 round.
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 leads at any point in time. Everyone involved can name it. Write access on the non-leading 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, 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, 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 request from an examination 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 holding 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 holding 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 leads also has to settle who reads from it and when leadership 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 any more.
Derivation: Follows from the same rule: naming a leading system 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 leadership 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 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 taken 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; it was overlooked. It belongs corrected before the first run, not defended when an auditor asks about it.
The statement is a document with signatures, not a job result. It is signed once and then sits in the evidence file.
The statement is retained for as long as the longest retention period of the holdings it explains. For German institutions that is normally the ten-year period under commercial and tax law.
Reconciliation and the opening balance statement look at the same data and answer different questions. Reconciliation asks whether everything arrived; the statement 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, 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 holdings 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 holdings, instrument master data, mandates, 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 statement, 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 holding: 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, a way back for every transition.
Count, value, attribute and the comparison against neighboring systems, at every transition and on a fixed rhythm. Tolerances in advance, differences with an owner and a deadline, evidence 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, new balance, per booking entity and currency. Here the result changes level, from processing into the balance sheet, and it acquires signatures.
With the statement signed off, the target platform leads, and it leads 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 requirement 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, 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 holding, 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 led 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.
Holdings in a form that stays readable without the retired application. Proven by checksums across the complete holding, 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, holdings under legal hold, operation of the archive, a recurring retrieval test, 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 holdings 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 leads in which phase, dual leadership arises. The bridge is then not a transition but a second book of record, with all the consequences for reconciliation, auditability and answers to the supervisor. 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, pure lookup systems. Here the more honest and cheaper route is this: holdings 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. Then 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.
We place the situation in context in a confidential conversation: what really has to come along, what belongs in the archive, and which piece of evidence is missing today for the retirement decision.