Handover Debt: Settling What a UK Aergo Pilot Leaves Behind

Most enterprise blockchain pilots are sold on a first hundred days. A proof of concept goes live, a few transactions settle, a steering group is shown a dashboard, and the story ends at the point of maximum enthusiasm. What happens next — the export, the handback, the slow decay of a network that nobody is paid to run — rarely appears in the business case at all.

That gap has a name worth adopting in the UK market: handover debt. It is the accumulated obligation a pilot builds up while it is busy proving something, and it falls due the moment the funding stops. Like technical debt, it accrues quietly and is cheapest to settle early. Unlike technical debt, it is usually somebody else's problem: the platform team, the records manager, the information assurance officer, or the supplier who won the follow-on contract and inherited a chain nobody documented.

The end of a pilot is a liability event

When a programme closes, several things happen at once on a permissioned Aergo network. The block producers stop being funded. The operations team moves on. The subscription that held the node alongside its monitoring and backup tooling lapses. And the organisation is left holding a ledger that still contains the evidence it was created to produce, accessible only to people who are busy elsewhere.

Treat that combination as an incident, not an administrative tidy-up. The question to answer is not "did the pilot prove the concept?" but "can this organisation still prove what the pilot recorded, in eighteen months, to an auditor or a regulator?" If the answer depends on a single engineer's laptop and a vendor's goodwill, the pilot has not finished — it has been abandoned.

Account for four kinds of asset, not one

Aergo deployments tend to blur together four distinct things, and handover fails most often at the seams between them.

The chain itself. Genesis configuration, consensus parameters, node topology and the full block history. This is the part teams remember.

The keys. Block producer keys, transaction signing keys, any administrative keys on permissioned contracts. This is the part teams forget, because during a pilot they live in a shared vault with informal ownership.

The contract logic. Lua contract source, any SQL-based contract definitions, deployment parameters, and the version history that explains why the deployed bytecode differs from the repository's head.

The off-chain evidence. Documents whose hashes were anchored on-chain but whose bytes live in an object store, a shared drive, or a supplier's system. Without these, the on-chain record proves that something existed and nothing about what it said.

A handover that transfers the first and not the other three is not a handover. It is a data loss event with paperwork attached.

Exporting the ledger without exporting the meaning

A raw chain export is necessary and largely useless on its own. Any receiving organisation needs three things alongside it: a node snapshot that can be started without a rebuild from genesis, a documented procedure for verifying that a given hash corresponds to a given document, and a plain-language register mapping each contract address to the business process it supported.

The register matters more than it sounds. Six months after a pilot ends, the people who knew that address 0x… was the goods-receipt attestation contract will have moved roles. A one-page table — contract, purpose, owner, anchoring frequency, retention class — is the difference between usable evidence and a very expensive hash archive.

Keys, custody and the awkward question of who signs

Key custody during a pilot is usually improvised. A block producer key sits with the delivery lead. An administrative key sits with an integration partner. Nobody has written down what happens when either leaves.

At exit, decide explicitly and in writing whether each key is transferred, rotated, or destroyed. Rotation is often the right answer for administrative keys, because the incoming operator should not inherit a credential with an unknown history. Block producer keys should be transferred through a documented ceremony with two named custodians and a record of the change, not by email.

If the network will be decommissioned rather than transferred, say so and mean it. A chain that is nominally live but has no funded block producers is worse than a chain that has been formally closed and archived, because it invites future teams to assume it is being looked after.

Contracts: freezing, migrating, or retiring with dignity

Three options are usually available, and each has a different evidentiary consequence.

Freezing is the cheapest. Leave the contract deployed, keep a single archive node running, and stop writing to it. The evidence trail stays intact and verifiable. The cost is a modest, indefinitely recurring one, and it should be budgeted before the pilot closes rather than discovered afterwards.

Migration to a production network carries the record forward but changes its context. If you migrate, migrate the evidence and not just the code: the historical hashes, the document register, and a signed statement explaining that the production chain's records begin at a stated height with a documented predecessor.

Retirement is legitimate where the pilot had no evidentiary purpose. It becomes indefensible where documents were anchored and then discarded, which is precisely the pattern a UK auditor will look for.

Retention duties that outlive the contract

UK records obligations do not stop when a project does. Company law, tax rules, sector regulators and the organisation's own retention schedule will each set a floor, and in practice the longest applicable period governs. Personal data processed during the pilot brings the UK GDPR and the Data Protection Act 2018 into play, with the storage limitation principle requiring a defensible answer to how long on-chain and off-chain records are held and why.

On-chain data complicates deletion. Hashes are generally not personal data in isolation, but they can become identifying when combined with the off-chain store, and that combination is exactly what a handover package contains. The exit plan should state, in advance, which fields were deliberately excluded from anchoring, how the off-chain store will be disposed of at the end of retention, and who authorises that disposal.

What a clean handover looks like

A workable sequence runs roughly as follows. Freeze writes and announce the closure to all participants. Take a final verified snapshot and rehearse a restore on clean infrastructure. Export contract sources and the address register. Execute the key ceremony and record it. Transfer the off-chain store with checksums matched against on-chain anchors. Publish a closure note that states what the network recorded, where it now lives, and who owns it.

Run that in a week and it is a controlled transition. Skip it and the organisation inherits a liability it will only discover when someone asks a question it cannot answer.

Put it in the pack, not the appendix

Portability belongs in the procurement documents from the first conversation, phrased as a deliverable with an acceptance test rather than a promise of cooperation. Specify the export formats, the key ceremony, the register, the retention schedule and the named recipient. Make the final payment conditional on it.

The measure of an enterprise blockchain deployment is not how elegantly it begins. It is whether, on the day it ends, the organisation can still prove what happened — and can do so without calling the person who built it.