Remediation timeline: a 90 day plan.

When a project you depend on relicenses, the worst response is an open ended one. Exposure that has no deadline tends to drift, and drift is what turns a manageable license change into an audit finding or a renewal ambush. A remediation timeline fixes that by giving the work a defined window. Ninety days is a useful default, long enough to map, decide, and act with care, short enough to keep the effort sharp. The plan below runs in three phases of roughly 30 days. It is not a promise to finish every migration in a quarter. It is a commitment to contain the largest exposure inside one, with a credible roadmap for whatever remains.

Days 1 to 30: map the exposure

The first phase produces a current dependency map and finds where the relicensed component actually sits in your estate, direct and transitive. It then sizes the exposure: what the restriction costs if it reaches your use, on which systems, and how urgently. This is the phase where the timeline succeeds or fails, because every later decision rests on it. Skip the map and you will remediate the wrong things, or remediate the right things in the wrong order. The phase ends with a ranked list of affected systems, sorted by exposure, which becomes the spine of the rest of the plan. We cover the discipline in how to respond in the first 30 days of a relicense.

Days 31 to 60: decide the path

With the map in hand, the second phase chooses how to respond. For each affected system the choice is to fork, migrate, pay, or, where the license does not reach the use, stay put. The decision is made with a cost model behind it rather than by reflex, weighing one time engineering, recurring spend, and the residual risk each path leaves. This phase also produces the sequencing plan: which systems move first, which follow, and what the fallback is if a chosen path proves harder than expected. By the end of day 60 you should have a path selected per system, a cost attached, and an order of execution. We frame the choice in fork, migrate, or pay: the remediation decision.

Days 61 to 90: execute by risk

The third phase puts the plan into production, highest risk systems first, each behind a test suite that proves nothing broke before the next one starts. Sequencing by exposure protects you fastest where the liability is largest and avoids a big bang change that risks an outage. A clean fork can often complete inside this window. A large migration may extend beyond it, but the highest risk systems are contained within the quarter and the rest sit on a tracked roadmap. A concrete example of an in window migration is in migrating from Elasticsearch to OpenSearch.

What to track across the remediation timeline

A 90 day plan needs a small set of measures that show whether it is on track. Track the count of affected systems mapped, the share with a path decided, and the share contained. Track the priced exposure remaining at each weekly checkpoint, so the board can see the liability falling rather than a list of tasks. Track the cost committed against the cost modeled, to catch a path drifting over budget early. These few numbers keep a remediation honest and turn status updates into evidence rather than narrative.

When the timeline should compress or extend

Ninety days is a default, not a law. A relicense with a near term effective date, or an audit already in motion, can compress the first phase and force a faster decision on the highest risk systems, with the map refined in parallel. A sprawling estate with the component everywhere may extend execution well past the quarter, in which case the plan still delivers a contained top tier and a sequenced remainder. The urgency of the timeline depends on whether the restriction actually reaches your use, which is a question for your own counsel. The full approach sits in our pillar on remediation and alternatives.