Every implementation is also a transfer of power. The contract either ends with the agency holding the knowledge to run the system on its own, or it ends with the vendor holding it on the agency's behalf. There is no neutral arrangement. A method essay on the architecture of dependency, and on how to do it the other way.
Read the average government IT contract carefully and a curious property emerges. The deliverables clause lists software modules, hardware, licences, documentation, training hours. The acceptance clause specifies tests and uptime. The support clause specifies response times and escalation paths. Nowhere in the document does the word capability appear. And yet capability — the agency's ability to run, change, evolve, and ultimately replace the system without the vendor — is the most important thing the contract should be procuring. Its absence from the document is not an oversight. It is the document's most consequential feature.
An implementation has two possible endings. In the first, the contract concludes and the agency keeps running the system. Its staff have the schemas, the workflows, the integration map, the test plans, the deployment scripts. They can extend a process, on-board a new department, add a regulatory rule, integrate a new partner agency, or migrate to a different infrastructure provider. The vendor remains useful for product roadmap, security patches, and major architectural work; but the agency is not dependent on the vendor for the day-to-day evolution of its own operations.
In the second ending, the contract concludes and the system continues to run, but the knowledge to evolve it does not live inside the agency. It lives inside the vendor's delivery team — their analysts, their senior consultants, their tribal documentation. Every change of consequence requires a statement of work. Every emergency requires the right person being available. Every renewal arrives with the leverage of the irreplaceable. The agency owns a system that, in practice, it cannot operate alone. We propose a name for this state: the agency has been captured.
Capability transfer is not a phase at the end of the project. It is a property of the architecture, the contract, and the operating cadence, present from the first day. A capture outcome is not a betrayal by the vendor; it is the predictable result of a contract that did not provide for the alternative.
Capture is rarely the product of bad faith. It is the product of a thousand small, individually defensible decisions that compound. The implementation needs to move fast; the vendor's experts are faster than the agency's analysts. A change is urgent; a change order is quicker than retraining the in-house team. Documentation is expensive; the vendor's institutional memory is free as long as the relationship holds. Each individual choice is the right one for that week. The accumulated effect, two years later, is an agency that cannot operate its system.
Four mechanisms account for almost all observed capture cases. The first is configuration drift without trace. The vendor's analyst makes a change in production; no commit, no review, no entry in a configuration log. The change works, the analyst moves on. Six months later, a new analyst cannot reconstruct why the rule fires the way it does. Only the original analyst knows, and the original analyst now works on another account.
The second is tribal integration knowledge. The system speaks to six others — the central bank's settlement gateway, the customs broker's manifest service, the cabinet office's shared identity, the tax authority's reporting endpoint. Each connection was negotiated by a different person; each has its own quirks; none is documented in a single map. The integration architect is the only person who knows where the bodies are buried, and the integration architect bills weekly.
The third is opaque customisation. The platform was nominally a product, but to fit the agency's operations the vendor added custom code in seventeen places — some inside the product, some on top, some as side-cars. The customisation works. The customisation is also incompatible with the next product upgrade unless the same vendor reapplies it. The agency now cannot upgrade the platform without engaging the vendor. The vendor's leverage on the upgrade conversation is, accordingly, total.
The fourth is training that demonstrated rather than transferred. The training delivered by the contract was a hundred hours of presentations and a passing assessment. Six months later, when the trained staff faced a real problem, they realised the training had shown them how the system works, but not how to make it work differently. There is a profound difference between the two, and most training programmes never cross the threshold.
To replace capture with transfer, capability must be defined precisely enough to be contractually delivered. We use a four-part definition. Capability is the combination of knowledge (the agency's staff understand the system's design), access (the agency holds the credentials, source, configuration, and infrastructure necessary to act), practice (the agency has performed the relevant operations independently, not merely observed them), and continuity (the knowledge survives staff turnover through documentation, training pipeline, and institutional repositories). A capability claim that lacks any of the four is a claim that has not yet been earned.
Capability transfer is delivered architecturally first, contractually second, and operationally third. The architecture must permit it; the contract must require it; the cadence must enact it. Reversing the order produces a contract whose obligations cannot be met by the architecture it bought — a common and quietly catastrophic failure pattern.
Architecturally, the platform must express its operational logic as configuration rather than code. When the platform's business rules, workflows, schemas, validations, reports, screens, and integration maps live as declarative metadata, the agency's staff can author and modify them at the metadata layer without compiling, without redeploying, and without depending on the vendor's developers. We have written elsewhere — in our build-vs-buy essay — about why configuration ownership is the actual prize in the build-vs-buy debate. The same property is the precondition for capability transfer. Without it, transfer is impossible regardless of how good the contract or how diligent the cadence.
Contractually, the obligations are concrete. The platform must permit named operations to be performed by agency staff. The configuration, in its entirety, must be the property of the agency. The integration map must be maintained in a documented, agency-readable format. Custom code, if any, must be isolated, documented, and migration-tested. Training must include a competence test that requires the trainee to perform real tasks unaided, against a defined rubric, and to pass it before the relevant project gate closes.
Operationally, the cadence enacts the architecture and the contract. From the first week, the agency's staff sit inside the implementation team rather than alongside it. They author configuration; the vendor reviews. They run deployments; the vendor supervises. They handle incidents; the vendor advises. The roles are reversed from the conventional pattern, in which the vendor delivers and the agency receives. In a transfer cadence, the agency does the work from the start, with progressively reducing scaffolding.
We model the transfer in three phases, with explicit gates between them. The phasing is not new — pilots have practised it for a century — but applying it to government IT requires discipline that most engagements do not impose on themselves.
Phase one — observed. Vendor performs; agency observes and is briefed. This phase exists for a single purpose: to expose the agency's analysts to the full breadth of what the system does, the operations that must be performed against it, and the categories of decision that arise. The phase ends when the agency's staff can describe, in their own words and to one another's satisfaction, what the system is and how it is intended to work. We do not let it end on a calendar date; we let it end on a comprehension test.
Phase two — supervised. Agency performs; vendor reviews and corrects. The work is real, not training. The configuration is the configuration that will go to production. The deployments are the deployments that will run. The vendor's role is to catch errors, explain why, and let the agency's staff fix them — not to take the keyboard. The phase ends when the agency can perform the agreed catalogue of operations independently to a defined standard. The test is again pragmatic: a panel of operations selected by the agency's auditor, performed live, observed by the vendor in silence.
Phase three — independent. Agency performs; vendor is on call. The vendor is no longer the executing party; it is a support contract. The work is now the agency's, and the proof that capability has transferred is that the agency can, in fact, sustain the system for a defined exit-test period — typically ninety days — without unscheduled vendor escalation. If the period passes, transfer is complete. If it does not, the cause is diagnosed and phase two reopens for the relevant area. There is no shame in failing the exit-test once. There is only shame in pretending it passed when it did not.
A capability transfer manifest, attached to the contract, enumerates what is actually transferred. The list is more concrete and less impressive than it sounds at first reading. The unimpressive specificity is the point.
First, the platform's operating credentials. Production access, administrative roles, infrastructure consoles, monitoring dashboards, secret stores. Held by the agency's named staff, not by the vendor's account managers. A credential held by the vendor is a capability the agency does not have.
Second, the configuration repository. All schemas, workflows, rules, reports, screens, and integration definitions, exported in a documented format, version-controlled in a repository owned by the agency. Not licensed back. Not held in escrow. Owned. The vendor receives access for support; ownership remains with the agency.
Third, the integration map. A documented inventory of every system the platform speaks to, the protocol, the message schemas, the credentials, the authentication mechanism, the responsible party on the other side, the test plan for each connection, and the recovery procedure if a connection fails. Held by the agency, updated by agreed cadence, audited annually.
Fourth, the operations runbook. The plain-language document that describes how to do each routine task — deployment, backup, recovery, on-boarding a new user, reconfiguring a workflow, generating a regulatory report. Written by the agency's staff during phase two, reviewed by the vendor, and continuously revised by the agency thereafter. A runbook written by the vendor is a transitional artefact. A runbook written by the agency is the proof that the agency understands its own system.
Fifth, the change history. Every configuration change since go-live, who made it, when, why, and what it affects. The change history is the agency's institutional memory in machine-readable form. Without it, the next analyst inherits a black box.
Sixth, the training pipeline. Not the training hours delivered to the original cohort, which are an asset that depreciates with staff turnover, but the pipeline that produces newly capable staff continuously — the materials, the assessments, the certifying instructor inside the agency. The Emeron Academy was built precisely so that this asset can be re-issued indefinitely, against an external standard, without dependence on us.
Translating the architecture and the operating model into contract language is a discipline of its own. Five instruments do most of the work.
The capability schedule. Attached to the master contract, it enumerates the named capabilities the agency will hold at exit. Each capability is testable. Each has an owning role inside the agency. Each has an exit-test specification. The capability schedule is the document the audit committee should read first.
The gate-and-test mechanism. Each phase has a gate. Each gate has a test. The test is not a presentation; it is a demonstration of the capability against a panel of tasks. Payment of the next milestone is conditional on the gate passing. The gate is not adjudicated by the vendor's project manager; it is adjudicated by the agency's independent auditor or, in larger engagements, by a joint steering committee that includes a non-vendor third party.
The configuration ownership clause. Discussed elsewhere in this body of work, the clause vests ownership of the running configuration with the agency, requires it to be expressed in an exportable format, and obliges the vendor to maintain that exportability through upgrades. Without this clause the rest of the transfer architecture is decorative.
The exit clause. Not a termination clause — every contract has one of those, and they are about money. An exit clause is about transition: the support level at which the agency can run the system independently, the artefacts that must be in the agency's hands at exit, the period during which the vendor must remain available for paid handover support, and the post-exit warranty on the artefacts delivered. A good exit clause is so detailed it embarrasses people. That is the right state.
The independent assurance clause. The agency's right to commission an independent third party — a different consultancy, an academic body, an audit firm — to assess capability transfer at any time during or after the engagement. The vendor agrees to cooperate. The cost is the agency's. The right exists not because we expect to use it often, but because its existence changes the incentive structure during the engagement. A vendor who knows they may be assessed by an independent party behaves differently from one who does not.
We have seen transfer programmes fail for reasons that are technical, contractual, and political. Four patterns recur often enough to be worth naming.
The hero analyst. One member of the agency's team turns out to be exceptionally capable. The implementation team gravitates toward them. They become the agency's interface to the vendor and the vendor's only conversation inside the agency. Six months in, capability has transferred to one person rather than to the institution. When the hero leaves — for promotion, for the private sector, for political reasons — the institution discovers it had outsourced not to a vendor but to a single colleague. The remedy is institutional from day one: rotations, pair work, written knowledge, and a no-single-point-of-knowledge audit done quarterly.
The seconded engineer who never leaves. A vendor engineer is embedded with the agency to accelerate the team. The acceleration is real. They are also so useful that, two years later, they are still embedded. The agency has not built capability; it has acquired a permanent vendor employee at a markup. The remedy is a planned tapering of vendor presence on a published curve, enforced by the gate-and-test mechanism, not by goodwill.
Training as ceremony. Hours of training are delivered. Certificates are issued. No test is administered against an external rubric. The training has not transferred capability; it has transferred attendance. The remedy is competence-based certification — ideally external, ideally with an exam that can be failed, ideally with a published pass rate. This is one of the reasons we have built the Emeron Academy as an external certifier rather than internal training.
The undocumented hotfix. Production catches fire. The vendor's senior engineer fixes it in twenty minutes. Everyone is grateful. No-one writes down what they did. Six months later the next fire is identical and the engineer is on another account. The remedy is a brutal post-incident discipline: no incident closed without a runbook update authored by the agency. Tedious. Universal. Effective.
The economic case for transfer is not subtle. A captured agency pays the same software costs as a transferred one plus the cost of continuous dependency — change orders for routine modifications, premium pricing on renewal, escalation fees for emergencies, integration projects for connections that should be standard. Across a typical platform lifecycle of fifteen years, the captured agency pays between forty and ninety per cent more than the transferred one, depending on jurisdiction and contract sophistication. The wide range is itself a statement: transfer outcomes vary by skill, not by luck.
The non-economic case is starker. A captured agency cannot make policy changes at the speed policy demands. Legislatures pass amendments faster than change orders can be processed. Crises arrive on their own timetable. A capability-captured agency loses, slowly, the ability to govern itself. There are no enquiries into this kind of failure because it is not visible as a single event. It is visible as a long, structural deceleration that nobody chose and everybody resents.
A note on the vendor side of this conversation, since we are one. Capability transfer is occasionally framed as adversarial — the agency wanting to get rid of the vendor, the vendor resisting. In our experience the framing is wrong. A vendor that has transferred capability successfully is the vendor that is invited back — for the next platform, the next sister agency, the next jurisdiction — because the relationship was a relationship rather than a hostage situation. A vendor that has captured the agency is the vendor that is renewed reluctantly and replaced at the first opportunity. The economics of trust outperform the economics of dependency over any meaningful horizon. We have made this our operating model not because it is virtuous but because it is also commercial.
At the end of every engagement we run a simple test. We ask the agency's staff, without the vendor in the room, to perform three things: deploy a configuration change end-to-end, on-board a new integration to a defined sister system, and produce a regulatory report from cold — meaning, without referring to the original implementation team. If they can do all three, transfer is complete. If they cannot, transfer is incomplete and we say so in writing. The test is short. It is also unfakeable. It is the standard the procurement officer should write into the contract, the auditor should administer at handover, and the minister should ask about by name.
The question is not whether the system has been built. The question is whether the agency has been built.
This essay is the public summary of Whitepaper WP-04 (74 pages, reviewed). The whitepaper includes the full capability schedule template, gate-test specifications, sample contractual clauses, and three anonymised post-mortems of transfer engagements — two successful, one not.
Why the classical debate misses the real question. Configuration ownership is the actual prize.
Read essay →Practical screening questions that surface vendor lock-in before it is signed into a multi-decade dependency.
Read essay →What sovereignty actually requires at the infrastructure layer, and why it is not solved by marketing.
Read essay →We run private capability-transfer reviews on draft contracts and SoWs for agencies considering platform engagements. The output is a written assessment with concrete amendment language. Confidential. Without charge for procurement teams in the next twelve months.