Removing a Dependency Without Breaking Production

When a component you depend on moves to the Business Source License or the Server Side Public License, the technical task that follows is rarely glamorous. You have to take something that already works in production and replace it without taking the service down, losing data, or changing behavior in ways your customers notice. Removing a dependency without breaking production is the discipline that makes that possible. It treats the swap as a controlled, reversible sequence rather than a single brave deployment, and it keeps the known component carrying real traffic until the replacement has earned the right to take over.

The instinct under time pressure is to rip the old component out and wire the new one in. That instinct is what breaks production. A safer path costs a little more up front and removes almost all of the risk that matters. This article describes that path. It pairs with the broader pillar on remediation and alternatives, and with our hands on open source remediation advisory, where we sequence this kind of work alongside engineering teams.

Isolate the dependency behind a seam

The first move in removing a dependency without breaking production is to put a seam between your code and the component. A seam is a thin interface, an adapter, that every call to the dependency passes through. If your code reaches the component in fifty places today, the seam reduces that to one. Once the seam exists, swapping the implementation behind it is a single change rather than fifty risky edits scattered across the codebase.

Building the seam first also surfaces how the component is really used. Teams routinely discover that a dependency they thought they used in one way is actually called in three, including one path no one remembered. The seam makes that visible before you change anything, which is exactly when you want to learn it. The work to introduce a seam is low risk because it changes structure, not behavior, and it can ship to production on its own ahead of any replacement.

Choose the replacement on more than engineering cost

With the seam in place, the question becomes what to put behind it. There are three broad answers. A community fork such as OpenTofu for Terraform, Valkey for Redis, or OpenSearch for Elasticsearch usually offers the smallest behavioral gap, because it began as the same code under an open license. A different component is a larger change but can be the cleaner long term home. A negotiated commercial license keeps the component exactly as is and changes only the terms you pay under. Each option carries an engineering cost, a license posture, and a timeline, and the cheapest on engineering is not always the soundest on license posture.

The choice should follow from the blast radius, not from whichever option a single engineer prefers. A component buried in one internal tool can take a heavier migration because the downside is contained. A component woven through a customer facing product deserves the option with the smallest behavioral gap, even if it costs more, because the cost of a surprise in production is far higher. For a structured way to make this call, see fork, migrate, or pay: the remediation decision.

Prove the replacement in shadow before it serves traffic

Documentation tells you how a component should behave. Shadow testing tells you how it actually behaves against your real inputs. In shadow mode, the replacement sits behind the seam and receives the same calls as the live component, but its output is compared rather than used. Every difference is logged. This is the cheapest way to find the gap between documented behavior and real behavior, and that gap is where production breaks. A fork may handle an edge case differently, round a number another way, or return errors in a different shape. You want to find each of those in a log, not in a customer complaint.

Run the shadow long enough to cover the full range of real traffic, including the peaks and the odd inputs that only appear occasionally. A replacement that matches for an hour at low load has proven very little. One that matches across a full business cycle, including the end of month spike and the unusual request that arrives twice a week, has earned real confidence. The comparison output becomes the evidence that supports the cutover decision.

Cut over in stages with a fast rollback

Once the shadow is clean, the cutover should still be gradual. Route a small share of traffic to the replacement, watch the metrics that matter, then widen the share in steps. A flag at the seam controls the split, so increasing exposure or rolling back is a configuration change rather than a deployment. If a problem appears at five percent of traffic, it affects five percent and is reversed in seconds. The same problem discovered at one hundred percent is an incident. Staging the cutover trades a little patience for the removal of the worst outcome.

Keep the old component in place and reachable until the replacement has run at full traffic for long enough to trust. Removing the old code is the last step, not an early one, and it should be a deliberate decision with its own review. Confirm that the change held under a real release cycle, and confirm that the security patch path for the new component is in place, since a fork or alternative has its own update cadence. For more on keeping releases steady through this work, see remediation and your release cycle, and for the failure modes to avoid, measuring remediation success sets out what a finished migration should look like.

RELATED READING