REMEDIATION AND ALTERNATIVES

Remediation prioritisation by risk and effort.

After a relicense, you rarely have the budget or the release windows to fix everything at once. Remediation prioritisation by risk and effort decides the order, so the work that removes the most exposure for the least cost happens first. This is how a long remediation list becomes a defensible plan.

When a project such as Terraform, Redis, or Elasticsearch moves to a source available license, the remediation list that lands on an engineering leader's desk is usually long. Several teams use the component. Some use it in production, some in tooling, some only in tests. Trying to remediate all of it in one sprint is neither possible nor wise. Remediation prioritisation by risk and effort gives you a method for ordering the work, so the first changes you make are the ones that reduce the most exposure for the least cost, and the rest follow in a sequence you can defend to your board. None of this is legal advice, and the question of whether a given use breaches a license belongs with your own counsel.

Why ordering matters more than speed

A remediation programme that starts with the easiest change rather than the most important one feels productive and protects very little. A programme that starts with the hardest change can stall for months while real exposure sits untouched elsewhere. The point of prioritisation is to avoid both traps. You want a sequence where each step is justified by the exposure it removes and the effort it takes, and where the order itself holds up if a regulator, a vendor, or your own audit committee asks why you did things in that order. Speed without sequence wastes budget. Sequence without speed leaves you exposed. The two axes, risk and effort, give you a way to hold both in view at once.

Scoring the risk axis

Risk is not a single number. For each affected component, three factors combine. The first is licensing exposure: how far the new terms reach into the way you actually use the software. A source available license that restricts competitive production use creates more exposure when the component sits in a product you sell than when it runs an internal dashboard. The second is blast radius: how many systems, teams, and downstream artifacts depend on the component, directly and transitively. A library three layers deep in your build can touch far more than its single line in a manifest suggests. The third is business criticality: whether the systems built on the component carry revenue, hold regulated data, or face customers. A component scoring high on all three belongs near the front of the queue regardless of how convenient it is to fix.

Mapping these factors requires an accurate inventory first. You cannot rank what you have not found, and transitive dependencies are exactly where a relicensed component tends to hide. The starting point for any prioritisation is the dependency tree produced by an assessment, which is why this work sits downstream of building an open source remediation roadmap rather than ahead of it.

Scoring the effort axis

Effort is the engineering cost to remediate a given component, and it varies far more than buyers expect. At the low end is a drop in replacement: a community fork that is wire compatible with what you run, such as OpenTofu for Terraform or Valkey for Redis as of 2024. Swapping to a compatible fork can be a configuration and testing exercise rather than a rewrite. At the high end is re architecture, where you remove the dependency entirely and rebuild the capability on something else. Between the two sit migrations that change interfaces, require data movement, or touch shipped software you no longer fully control. Effort also includes the testing burden and the release windows available, because a change that is small in code can still be slow to ship safely in a regulated release cycle. The honest cost comparison across these paths is the subject of the cost model of each remediation path.

Reading the grid: four quadrants

Plot every component on a simple grid with risk on one axis and effort on the other, and four groups appear. High risk and low effort items are the clear first wave; they remove real exposure quickly and build momentum. High risk and high effort items are the ones that need the most planning, because you cannot rush them and you cannot ignore them. These often run on a stopgap, such as a frozen version under a holding pattern, while the larger migration proceeds. Low risk and low effort items are useful filler for spare capacity between the larger pieces. Low risk and high effort items are the candidates to defer or drop entirely, since the exposure rarely justifies the cost. The grid turns a flat list into a plan, and it makes the order easy to explain.

When the highest risk item cannot go first

The most common mistake is to assume that the single highest risk component must always be remediated first. Sometimes it should. But if that component needs a year of re architecture, fixing it first means a year during which several other high risk items also sit exposed. Often the better sequence clears a handful of high risk, low effort items in the first weeks, contains the hardest item on a documented stopgap, and then works the long migration in parallel. Prioritisation accounts for the cost of leaving exposure in place during the work, not only the cost of the work itself. The decision of whether to fork, migrate, or pay for each component feeds directly into this, and it is worked through in fork, migrate, or pay: the remediation decision.

Keeping the plan honest as it runs

A prioritised plan is a snapshot, not a fixed schedule. New dependencies surface, a fork's compatibility turns out better or worse than expected, and business priorities shift. Review the grid at each milestone, move items as the facts change, and record why. The same discipline that lets you defend the order at the start lets you defend the changes later. Closing the loop means agreeing in advance what success looks like for each item, so you know when a component is truly remediated rather than merely touched, which is the focus of the 90 day remediation timeline.

The buyer side view

We build the risk and effort grid for your specific estate, score each affected component with your engineering leads, and hand you a sequenced plan with the reasoning attached. We are independent and paid only by you, never by a vendor or a reseller, so the order we recommend serves your exposure and your budget rather than someone's renewal target. The full set of options sits in the open source remediation and alternatives pillar, and when a path needs hands on scoping we run it through our open source remediation advisory engagement.

COMMON QUESTIONS

Questions buyers ask.

CONTAINMENT

Sequence the remediation before the budget runs out.

A confidential open source remediation advisory engagement. Independent, buyer side, paid only by you.

Not ready to talk? Read the free open source license risk guides first.