Decommissioning a Source System: Proving Quiescence

The last phase of a migration is the one with the least schedule pressure and the most permanent consequences. Turning off a source system is irreversible in a way that the cutover was not, because the cutover had a fallback and the shutdown does not. Quiescence is the property that justifies the shutdown: nothing reads from the source, nothing writes to it, and nothing depends on it existing.

Idle is not the same as unused

A system that reports no requests is either unused or unreachable. The two look identical from the system’s own metrics, and confusing them is the characteristic error of decommissioning.

The distinction matters because the causes are opposite. An unused system has no callers. An unreachable system has callers who are failing, and their failures may be silent. A client with a retry policy and a dead endpoint will retry indefinitely and report nothing, or will fall back to a stale cache and continue serving slightly wrong data. Neither shows up as traffic at the source, because the traffic never arrives.

The measurement that distinguishes them has to be taken at the caller, not at the callee. Counting inbound connections at the source proves that nobody reached it. Counting outbound attempts at the callers proves that nobody tried. The second is the one that matters, and it requires an inventory of callers that is complete, which returns to the problem of dependency discovery.

Where a complete caller inventory is unavailable, an indirect signal substitutes: the error rate at the destination. If every caller has been repointed, the destination’s request volume should equal the source’s former volume, within the difference caused by clients that stopped calling. A destination receiving substantially less traffic than the source used to receive means some callers are neither reaching the source nor the destination, which means they are failing somewhere.

Negative evidence needs a window longer than the longest period

Proving that no traffic arrives is a negative claim, and negative claims are bounded by the observation window. A window of a week cannot rule out a monthly job. A window of a month cannot rule out a quarterly report or an annual close.

The window must therefore be at least as long as the longest period in the system’s behaviour, and the honest answer is usually that the longest period is unknown. Two techniques make the claim defensible despite that.

The first is to derive the period from evidence rather than guess it. A source system’s own logs, its access records, and its billing records all contain the history of its usage. If the source has been running for years, its logs show every periodic caller that ever existed, including the ones that have since stopped. Analysing the full history for the longest gap between accesses by a given caller gives a lower bound on the period for that caller, and the maximum over all callers gives the window the decommissioning requires.

The second is to leave the source in a state where a late caller produces a loud failure rather than a silent one. A source that is stopped but still resolves produces connection refusals that a caller can log. A source whose name is removed from DNS produces resolution failures that are equally visible. A source that is deleted produces nothing at all. The sequence from reachable to deleted should pass through a stage where the failure is observable, and that stage should last long enough for the observation to be meaningful.

The dependency that survives the workload

A workload is easy to enumerate. What survives it is harder: the records, the credentials, the names, and the contracts that referenced it.

Retention obligations. Data in the source may be subject to a retention period imposed by policy or regulation, and the period may be longer than the migration’s duration. The obligation attaches to the data, not to the system, so it can be satisfied by exporting to an archive before deletion. The export must be readable without the source system, which rules out a backup in the source’s proprietary format unless the source’s software is retained to read it. This is the specific trap: a backup that requires the decommissioned system to restore is not a backup, it is a deferral.

Credentials and certificates. A service account, a TLS certificate, or an API key issued by or for the source continues to exist after the workload stops. Left in place, it is an unused credential with whatever access it was granted. The decommissioning should revoke it, and the revocation should be verified by attempting to use it, because a revocation that was requested and not applied is indistinguishable from one that was never requested.

Names. A hostname or a service record that pointed at the source will continue to resolve until it is removed. If it is removed while a client still resolves it, the client fails. If it is left, it points at nothing or at something that has been reassigned, which is worse. The order is to confirm no resolution attempts occur, then remove the record, then confirm no resolution failures occur, which is the same negative-evidence problem at the naming layer.

Contracts. A vendor relationship, a licence, or a support agreement attached to the source has a termination notice period and possibly a minimum term. These are not technical and they are the ones that determine whether the shutdown saves anything, because a system that is powered off but still under a minimum-term contract continues to cost its full price.

Why the last step is a restore, not a shutdown

The instinct is to shut the source down and consider the migration complete. The stronger final step is to restore the destination from its backups and verify that the restored copy is usable, before the source is deleted.

The reason is that the source is the only remaining fallback, and deleting it converts every latent backup defect into an unrecoverable one. Backup systems fail in ways that are invisible until a restore is attempted: a backup that excluded a tablespace, a retention policy that expired the only full backup before its incrementals, an encryption key that was rotated after the backup was written. None of these are detectable by inspecting the backup catalog. All of them are detectable by restoring.

The restore test should be performed against a copy of the destination, at full scale if the data volume permits, and it should include the operations that matter rather than only the data. A restored database that opens and answers a count query has demonstrated that the pages are readable. It has not demonstrated that the application can run against it, which requires the schema, the sequences, the grants, and the configuration to be present and consistent.

The result of the test is the actual recovery point objective. A backup taken every hour with a restore that takes six hours gives a recovery point of one hour and a recovery time of six, and both numbers are properties of the whole chain rather than of the backup schedule. Recording them is what makes the decommissioning decision informed.

The shutdown sequence and what each step can still undo

Ordering the final steps by irreversibility gives a sequence in which every step is reversible until the last.

Stopping the service is reversible: it can be started again, and the data is unchanged. Making the source read-only is reversible in the same way. Removing the name from DNS is reversible for the TTL duration, and the TTL should be short at this stage for exactly that reason. Revoking credentials is reversible only if the revocation can be undone, which for many systems means issuing a new credential rather than restoring the old one, and that changes every caller. Deleting the data is not reversible at all, and deleting the backups is the point at which the decision becomes permanent.

The interval between removing the name and deleting the data is the last window in which a missed caller can be discovered cheaply. It should be measured in the same units as the observation window, not in hours, and the decision to shorten it should be explicit rather than a consequence of the schedule.

A migration that ends with a deleted source and an untested restore has traded a known system for an unknown one, and the trade is only visible when the destination fails. The reverse order, restore test first and deletion last, costs a fraction of the migration’s total effort and removes the largest single unknown. That is the whole argument for treating decommissioning as a phase with its own criteria rather than as the administrative tail of the cutover sequence.