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.
Framework #77 — Dependency Residue
Dependency residue is the economic, operational, contractual, or governance dependency that persists after a transformation program declares its originating system, platform, service, or capability eliminated, and that the program's cost model no longer counts.
| Stage | What happens |
|---|---|
| 01 — The Condition | A transformation program defines what is being eliminated — a platform, service, contract, or capability — and its cost model draws the boundary there. |
| 02 — The Boundary | The cost model stops counting the eliminated dependency. The boundary follows accounting lines: budget owner, invoice, contract. |
| 03 — Failure State | Runtime, contractual, operational, or governance paths still depend on it. The dependency follows execution and obligation lines, not the ledger. |
| 04 — Consequence | The residual dependency keeps generating cost or exposure after the program reports complete, outside any line item the program still owns. |
The program closes against its cost model. The dependency never agreed to that boundary, so the cost moves outside the model instead of ending.
Related frameworks:
- #143 Dependency Visibility Boundary — whether a dependency can be seen at all; #77 is whether a seen dependency is still counted once elimination is declared.
- #137 Operating Model Transfer Gap — the governance that must be recreated on the target; #77 is what the source still costs while that recreation is incomplete.
- #78 Stranded Capacity Risk — capacity bought and never used; #77 is dependency the model stopped counting.
- #76, #79, #80 — shared origin in the repatriation economics model; common origin, not common mechanism.
Full library: Rack2Cloud Framework Index
Download: Framework #77 — Dependency Residue (PDF, one-page reference)
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.
01 — Compute moved. Identity didn't.
The cost model scoped the workload: instances, storage, runtime, the line items with a platform owner. The dependency followed the authentication path: service accounts, federation trusts, and conditional-access policy, all still anchored to the directory the program was leaving. The residue bills as the identity tenant nobody can retire, plus the licensing, logging, and privileged-access tooling that come with it. The same omission can end two ways. When the excluded identity dependency breaks, you get a migration that succeeded while the identity chain didn't. When it holds, you get residue. It keeps working, and it keeps costing.
02 — Hypervisor changed. Backup tooling didn't.
The cost model scoped the hypervisor subscription. The dependency followed the backup and migration tooling, which reads VMware virtual disks through a library whose distribution the vendor controls and whose license restricts redistribution. Exits aren't instantaneous. For as long as any VMware estate remains to protect or to move, some tooling can depend on access to VDDK, and when Broadcom's public VDDK download pages stopped resolving in August 2026, tooling that depended on obtaining the library through that route lost that acquisition path. That is the circular dependency a VMware exit plan assumes it controls, priced at zero the moment the hypervisor line left the model.
03 — Contract terminated. Audit exposure didn't.
The cost model scoped the subscription and stopped counting at termination. The dependency followed the contract's survival clauses, because audit rights can outlast the exit. The residue is everything required to answer one: retained deployment evidence, license-position records, the people who know what ran where, and the legal time to respond. None of it has a budget line once the vendor doesn't.
04 — Platform replaced. Operating process didn't.
The cost model scoped the platform. The dependency followed the operating model: change procedures, runbooks, monitoring conventions, and escalation paths written around the old platform's constructs. Where that operating context is never re-established on the target, teams keep the old process alive by hand: parallel tooling, retained specialists, a console someone still logs into. The platform left the model. The process kept its headcount.
05 — Application migrated. Data gravity didn't.
The cost model scoped the application tier. The dependency followed the data. Source-of-truth datasets too large, too regulated, or too entangled to move on the application's schedule stay where they were, and data gravity pulls the application back across the gap on every query. The residue bills as egress, replication, latency workarounds, and a storage estate that was supposed to be decommissioned.
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.
Download: Dependency Residue Carousel (PDF, 8 slides) — the five cases on a single swipe.
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.
| Mechanism | Question it answers |
|---|---|
| Dependency Visibility Boundary (#143) | Could we see the dependency? |
| Operating Model Transfer Gap (#137) | Was the operating context recreated on the target? |
| Exit cost as a first-class metric | What will leaving cost, priced before commitment? |
| Audit rights outlasting the exit | Which legal obligation survives the declared exit? |
| Dependency residue (#77) | What did the cost model stop counting while the dependency remained? |
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.
| Boundary question | What to trace | Residue signal |
|---|---|---|
| What was declared eliminated? | Runtime calls, credentials, network routes | The old endpoint is still being invoked |
| Which service was removed from the model? | Authentication and authorization paths | A credential or trust relationship remains active |
| Which contract was terminated? | Operational obligations and evidence paths | Audit or compliance activity is still required |
| Which platform was replaced? | Backup, monitoring, and automation execution | Old tooling still runs or still has to be able to run |
| Which data path was migrated? | Replication, access patterns, egress | The old location still incurs cost |
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.
If you want an independent read on what your program's cost model isn't counting, the Migration Readiness Assessment covers it.
Architect's Verdict
Dependency residue isn't an estimating error. A cost model can be right about everything inside its boundary and still be wrong about the program, because the boundary was drawn around the things that had an invoice and an owner, and the dependency was never obliged to respect that line.
The real problem is that transformation programs close against the ledger. Identity, backup tooling, audit obligations, operating process, and data all follow execution and obligation paths the ledger doesn't record. So the savings get reported at the boundary, and the residue gets paid somewhere outside it, by a team that never agreed to carry it.
The cost-model boundary is not the dependency boundary. Closure is a runtime claim, not an accounting one, and it should be tested like one.
A dependency isn't gone when the cost model stops counting it. It's gone when nothing still calls it, bills for it, or can be held to it.
Additional Resources
- Cloud Architecture Strategy — placement, economics, and dependency decisions across cloud and hybrid estates.
- Economic Architecture — exit modeling and economic gravity as continuous design disciplines.
- Dependency Architecture — classifying dependencies before exit pressure arrives.
- Vendor Relationships End. Audit Rights Often Don't. — the legal and contractual counterpart to this post.
- Exit Cost as a First-Class Metric — pricing the cost of leaving before commitment.
- Your VMware Exit Plan Assumed a Tool You Didn't Control — the VDDK case behind card 02.
- Your Migration Succeeded. The Identity Chain Didn't. — the outage outcome of the card 01 dependency.
- The Hypervisor Is Not the Migration Target — The Operating Model Is — Framework #137, behind card 04.
- The Law of Data Gravity — why datasets anchor the applications that leave them.
- VMware Licensing Pressure Created a Dependency Audit Problem — Framework #143, the visibility boundary.
- The Capacity You Paid For But Never Used — Hidden Cost Models Part 2.
- Broadcom Removes VDDK Pages Without Explanation — ShapeBlue — the August 2026 download-page failures and their acquisition-path impact.
- Developing for VMware Platform Products — Virtual Disk API (Broadcom) — VDDK's data-protection role and its redistribution requirements.
- Data Gravity — in the Clouds — Dave McCrory (2010) — the original data gravity post.
Originally published at rack2cloud.com
Top comments (0)