A replaced invoicing system has had no inbound API traffic for 45 days and no user logins for 60. The team is ready to switch it off. One engineer notices that the old system still allocates the sequential invoice numbers the general ledger expects to be gapless. What must happen before shutdown?

What is actually being tested

Whether you know that traffic monitoring finds callers and misses emissions. Forty-five days of silence on the inbound side is good evidence that nothing invokes the system. It is no evidence at all about what the system produces on its own: a numbering sequence, a nightly file dropped on an SFTP server, a signed certificate, a scheduled report, a mail relay role, a licence check that another product performs against it.

An allocated identifier is the hardest of these, because the dependency is on the sequence rather than on the system, and a sequence has state. Switching the system off does not produce an error anywhere. It produces an invoice numbered from a different counter, which the ledger rejects at the next close, weeks later, with no connection to the shutdown in anybody's mind.

The reasoning

The handover has three parts, and all three are needed before shutdown:

1. Read the current high-water mark from the old system and seed the new allocator above it, with a deliberate margin for anything in flight. Gapless means strictly increasing with no missing values, so the margin has to be reclaimed rather than skipped, or the first close after cutover fails on the gap.
2. Make allocation atomic with the invoice's own write in the new system, so a crash between allocating a number and persisting the invoice does not burn one. A sequence that can skip is not gapless, and most database sequences skip by design on rollback.
3. Run one full close with the new allocator while the old system is still able to run, so the failure mode is a rollback rather than a reconstruction.

Why the other options fail

• Keep it running read-only for twelve months. Read-only would break the allocator, since allocation is a write. This option also makes the shutdown nobody's job for a year, which is how replaced systems survive a decade and the business case's saving never appears.
• Export and switch off as planned. Correct for the data obligation and silent on the live one. The archive preserves the invoices and not the counter, and the failure surfaces at the next period close rather than at shutdown.
• Ask the ledger team to accept gaps. Occasionally the right conversation and usually not available: gapless numbering is frequently a statutory requirement for tax invoices, so the ledger team cannot grant it even if they want to.

The checklist that catches this

A decommissioning inventory with a row for every output as well as every input. Scheduled jobs and what they emit. Files written anywhere outside the system. Identifiers and sequences allocated. Certificates, keys and secrets the system owns. Infrastructure roles it quietly fills. Reports and extracts, with their frequency, because an observation window of 45 days cannot see a quarterly job and no window shorter than the longest business cycle proves anything.

When this is the wrong answer

If the numbering has no statutory or reconciliation requirement behind it and the ledger genuinely tolerates gaps, choose the clean break: a documented discontinuity costs one conversation, and a migrated allocator costs a seeded sequence, an atomicity guarantee and a rehearsed close. And if the old system's allocator is the only thing left running in production, the honest move is a progressive shutdown rather than a date: make it read-only, see what breaks, then stop it, then remove it, with each stage reversible. The general rule is that an output you cannot hand over is a reason to keep the system running, and an output nobody needs is a reason to stop it today; the inventory is what tells you which one you have.