Dependency Residue: The Most Expensive Dependency Is the One You Think Is Gone

Dependency residue is the cost that keeps arriving after a transformation program has formally eliminated the thing that generates it. The decommission ticket closes. The program reports complete. The steering committee sees the savings line it was promised. And somewhere outside the boundary the cost model drew, a service account still authenticates against the directory you were leaving, a backup job still depends on a library controlled by the vendor you exited, and an audit right still survives the termination.

None of that necessarily means the forecast was wrong. The model may have been right about everything it measured. It measured the wrong perimeter.

The Cost Model Drew a Boundary. The Dependency Didn’t Agree.

Every transformation program has two boundaries, and most programs only draw one of them.

The first is the cost model’s. It is drawn where things have an owner and an invoice: the hypervisor subscription, the instance fleet, the SaaS contract, the data center lease. Cost models follow accounting boundaries because that is what they are built from. A line item either exists in the model or it doesn’t, and when the program eliminates it, the model records the saving.

The second is the dependency’s. It is drawn wherever execution and obligation actually run: which systems call which, which credentials authenticate where, which data is read from which location, which contract clauses survive which events, which runbooks assume which platform. Dependencies follow execution and obligation boundaries, and they have no reason to align with a budget line.

The boundary used by the cost model is not the boundary used by the dependency. That gap is the whole mechanism. When a program declares something eliminated, it is making a claim about the first boundary and assuming it holds for the second.

The same boundary problem appears in cloud architecture strategy: placement is often priced at the service or infrastructure boundary while dependencies execute across identity, data, network, and operational boundaries. Transformation programs inherit that mismatch and apply it at the moment it costs the most: closure.

Dependency Residue Is Not a Repatriation Problem

Rack2Cloud first named dependency residue inside the repatriation economics model behind the Cloud Repatriation Economics Engine. The repatriation case is clean: compute comes home on schedule, while identity, observability, and CI/CD stay anchored to the provider being left. The workload moves. The authority layer governing it doesn’t. The program reports complete while the cloud bill keeps arriving.

Repatriation exposed the mechanism. It didn’t define it. Nothing in that pattern depends on the direction of travel, the platform involved, or whether the thing being eliminated is infrastructure at all. Any transformation program that declares something gone and measures that claim against a cost model is exposed to the same error. The framework is therefore generalized here as a property of transformation cost models, with repatriation as its originating instance rather than its scope.

That places it squarely in Economic Architecture, the Cloud Architecture Learning Path stage that treats exit modeling as a continuous discipline rather than a migration-time surprise. Residue is what that discipline misses when the model’s boundary is drawn at the line item instead of the dependency.

Five Transformations, One Boundary Error

If dependency residue were only a repatriation artifact, it would show up in one kind of program. It shows up in all of them. The five cases below are deliberately unlike each other: different layers, different platforms, different kinds of elimination. Each one reads the same way: what the cost model scoped, what the dependency actually followed, and where the residue now bills.

Every card borrows its evidence from a mechanism this site has already documented. That is deliberate, and it is the point. Those mechanisms explain why each dependency survives the transformation. Dependency residue explains why the cost model reported it gone anyway. The survival is the evidence. The miscount is the framework.

The pattern also isn’t new to this series. The capacity you paid for but never used is the same class of blind spot from the other direction: a cost the model counted and the organization never consumed. Residue is a cost the organization still consumes and the model no longer counts.

This Isn’t the Audit-Rights Problem. It Isn’t the Exit-Cost Problem Either.

The closest misreading of this article is that it restates one of its neighbors. It doesn’t, and the difference is worth making explicit, because a program team that treats them as one problem will fund one fix and assume all four are closed.

Vendor relationships end, but audit rights often don’t. That post tracks what survives legally or contractually after a declared exit. This post tracks what survives economically or operationally after a declared elimination. Card 03 above sits on the seam between them: the audit clause is the obligation that survives, and the residue is the cost of being able to answer it, which the cost model dropped at termination.

Exit cost as a first-class metric prices the cost of leaving before commitment, at adoption time, so the exit premium is visible before it is locked in. Residue is the other end of the same lifecycle. It is what the elimination model fails to count after the program has already declared the exit done.

And the dependency audit problem that Framework #143 anchors is about visibility: dependencies that can’t be reconstructed from configuration and documentation alone. Residue doesn’t require invisibility. A fully mapped dependency still becomes residue the moment the cost model stops counting it.

A program can pass the first four questions and still fail the fifth, because the fifth question is asked of the cost model itself.

Finding Dependency Residue Before the Program Closes

The fix is not simply a better spreadsheet. A more detailed version of the same cost boundary still misses whatever the program has already declared outside scope. The fix is to test the closure claim against the dependency boundary before the program is allowed to close: trace what is actually running, authenticating, replicating, and obligated, and compare it to what the model says is gone.

The middle column below is deliberately runtime-oriented. Ledger evidence confirms the cost model’s claim, which is the one claim that doesn’t need confirming.

Building the register this requires is the work of Dependency Architecture, the Learning Path stage where dependencies are classified before migration, consolidation, or exit pressure forces the question. Closure review is where that register gets tested against what the program claims.

Not every residue signal can be eliminated before closure. Retention periods, regulatory obligations, and datasets that genuinely can’t move on schedule are real. The discipline is not zero residue. It is zero uncounted residue: anything that survives the elimination gets a named owner and a budget line before the program reports complete. Counted, it is a known ongoing cost. Uncounted, it is the most expensive dependency in the estate, because nobody is managing it and everybody thinks it is gone.

Additional Resources

About The Architect

R.M.

Senior Solutions Architect with 25+ years of experience in HCI, cloud strategy, and data resilience. As the lead behind Rack2Cloud, I focus on lab-verified guidance for complex enterprise transitions. View Credentials →