A fallen tree in an old-growth forest is not a dead thing. It’s a different kind of living thing.
Within weeks of falling, fungi colonize the bark. Insects follow — bark beetles, carpenter ants — beginning to break down the structure. Moss covers the surface, retaining moisture. Over years, the log softens. Seedlings take root in it, drawn by the nutrients and consistent moisture the rotting wood provides. The fallen tree becomes a nurse log — the foundation for the next generation of the forest. Trees that began their lives in a nurse log sometimes grow in a colonnade, a line of mature trees marking where a giant once fell.
The fallen tree isn’t finished. It’s just doing different work.
This is decomposition: not the end of a thing’s contribution, but the transformation of it. The forest wastes nothing. Every dead thing feeds what comes next. The question is only whether you let it, or whether you clear it out before it can.
IT clears it out before it can.
In most organizations, decommissioning a system looks like this: a date is set, data is exported somewhere, the system is turned off, and the team moves on. The new system is running. The old one is gone. The project is done.
Six months later, a business process produces wrong results. An edge case surfaces that the new system doesn’t handle. A question comes up about historical data the export didn’t capture. Someone asks why the old system did a specific thing a specific way, and there’s nobody left who knows.
The system was switched off. It wasn’t decomposed. The nutrients went with it.
What Gets Buried
Business rules. Legacy systems accumulate business logic over decades — rules encoded in conditional branches, stored procedures, configuration values nobody remembers setting. Some of these rules are wrong and should die with the system. Many are correct, responding to real edge cases the business encountered and handled. When the system goes dark without documentation, the rules go with it. The new system rediscovers them slowly, through failures.
Historical data in unusable form. The data was preserved — technically. It was exported to a flat file, or archived to a drive, or backed up somewhere. But it wasn’t migrated in a form that can be queried, joined, or analyzed. It’s buried, not decomposed. The nutrients are there, locked in a form nothing can absorb.
The zombie. A system that should have been decommissioned but wasn’t, because everyone is afraid of what might break. It still runs. It still costs. Someone still gets paged when it fails. It’s consuming resources without contributing to anything. A fallen tree trapped in amber — not decomposing, not providing habitat, just occupying space and slowly becoming a liability.
The knowledge that lived in people. The person who built the system is gone. The system is off. The reasons for decisions — why the integration works that way, what the retry logic is protecting against, what the business was thinking when that rule was written — those existed in one person’s head and are now gone. The forest lost its mycorrhizal thread.
What the Carbon Cycle Says
In a forest, a fallen tree releases carbon slowly over decades as it decomposes. Remove it — clear it out as a logger would — and that carbon leaves the ecosystem immediately. The forest is poorer for the loss.
Information and knowledge are the carbon of IT systems. A system that’s been running for ten years has accumulated something: business rules, data history, integration patterns, learned behaviors. When it’s switched off without decomposition, that carbon leaves the ecosystem immediately — not captured in documentation, not migrated into the new system, not held in any form the organization can draw from.
The loss is invisible. The new system runs. The metrics look fine. But the organization is operating with less accumulated knowledge than it had before, and it won’t notice until something surfaces that the old system knew how to handle.
What Decomposition Actually Looks Like
Inventory what the system does. Not what the documentation says — what the system actually does. Run it. Trace it. Map the business rules in its behavior, not its spec. The same documentation work from the succession post, applied to a system on its way out rather than on its way through.
Extract the knowledge before it’s gone. Business rules documented in plain language. Historical data migrated to a queryable form, not buried in a flat file. Integration details captured — what upstream systems send, what downstream systems expect, what would break if it changed. The people who built it interviewed while they’re still available.
The nurse log phase. Run the old system alongside the new one long enough for edge cases to surface. The old system teaches the new one. Users move to the new system but the old one remains available as reference. This isn’t indecision — it’s intentional decomposition. The fallen tree is still providing habitat while it breaks down.
The snag. Even after the system is off, some artifacts are worth keeping accessible: the codebase in a read-only repository, the data archive in a queryable store, the documentation where people can find it. A standing dead tree — a snag — provides critical habitat for wildlife long after the tree has stopped living. Code in a read-only repo can still answer questions years later. It costs almost nothing to keep it there.
The forest doesn’t waste anything. A fallen tree becomes soil. A standing dead tree becomes habitat. Everything that was alive continues to contribute in a different form, for as long as the ecosystem is willing to let it.
The question for every system on its way out isn’t “when do we turn it off?” It’s “what does it still have to give, and how do we make sure it gives it before it goes?”
Switch it off when it’s ready. Not before.