The Pentagon's New Dependency Is Code, Not Advice

For twenty years, the consulting deliverable was a document. A strategy, a roadmap, an architecture diagram with a target state three years out. When the engagement ended, the agency kept the binder and the dependency ended with it.

That is not what gets delivered now. The same firms, plus the hyperscalers and the model vendors, arrive with engineers and leave behind a pipeline, a set of infrastructure definitions, a permission model and a production endpoint. The advice was never the valuable part. The running system is.

This is not a scandal. It is a better outcome for the mission in most cases, and a worse one for the buyer's bargaining position. The exit cost moved from a recompete to a migration, and most contracts were written for the first.

The deliverable changed, so the exit changed

A recommendation is easy to walk away from. You disagree, you buy a different recommendation, and the money is already spent.

A deployed system is different in three ways that matter at the end of a contract.

The artifacts are in someone else's repository. The infrastructure definitions, the deployment scripts, the environment configuration. If they live in the integrator's tooling and arrive as a zip file at closeout, they arrive without the history, the tests or the ability to reproduce the environment they describe.

The operational knowledge is in someone's head. Why the queue has that retry policy. Which service account is load-bearing. What the workaround is for the thing that never got fixed. That knowledge is not in the runbook, because the runbook was written at go-live and the system changed since.

The switching cost is technical, not commercial. Competing a contract is a procurement action. Migrating a pipeline, a data store and an identity model is an engineering program with its own authorization. The second is what an agency actually faces, and it is not priced in the recompete.

A vendor that leaves code behind has not left. It has installed itself in the architecture.

Why the lock-in is quieter than it used to be

The old lock-in was a license. You could see it, price it and argue about it.

The current version is diffuse. It is an egress fee that makes moving data expensive. It is a managed service with no equivalent elsewhere, so the code is portable and the behavior is not. It is a permission model woven into one cloud's identity system. It is a model endpoint whose version you do not control and whose deprecation date you do not set.

Cloud policy has pushed agencies toward commercial platforms for fifteen years, first with Cloud First and then with Cloud Smart, and the direction has not reversed. That makes the lock-in question more important, not less. A policy that says "use commercial cloud" needs a companion discipline that says "and be able to leave."

None of these are reasons to avoid commercial platforms. They are reasons to negotiate the exit while you still have options, which is before the system is in production.

What a buyer can actually require

Five clauses and one architectural habit. All of them are ordinary, and all of them are cheaper before award than after.

1. The infrastructure definitions live in the government's repository, from day one. Not delivered at closeout. Committed continuously, with the pipeline that applies them.
2. The pipeline is reproducible by a third party. A clean environment built from the repository, by someone who is not the incumbent, within a defined period. Test this during the contract, not at the end.
3. Egress and portability terms are explicit. What it costs to move data out, in writing, for the life of the contract and after it.
4. The runbook is a deliverable with a maintainer. Updated on a schedule, reviewed by the government, and tested by having someone else follow it.
5. An exit plan is required at award, not at recompete. A named migration path, an estimated cost, and the artifacts required to execute it. If the plan is stale in year three, that is a finding.

The architectural habit is narrower: keep the parts that encode your business rules out of the vendor's proprietary layer. Business logic in a portable service can be moved. Business logic expressed as a vendor's workflow configuration cannot.

The opportunity for a smaller firm

There is a business in the exit, and it is underserved.

Large integrators are paid to build the dependency. Very few firms are paid to reduce it: migration, remediation, the independent reproduction of another company's pipeline, the audit that tells an agency what it actually owns. That work requires exactly the skills the hyperscalers are hiring for, and it does not require competing with them on scale.

The firms that will matter in five years are not only the ones that can build the system. They are the ones that can hand it over, prove it works without them, and be hired again because the handover was clean. That is a harder pitch than transformation, and it is the one an agency remembers at recompete.