A 30-month database migration was funded entirely on the vendor's end-of-support date. Oracle was reported in February 2025 to have moved Premier Support for Database 19c out to the end of 2029 with Extended Support to the end of 2032. What happens to your programme over the next two quarters, and what do you change this week?

What happens, quarter by quarter

Quarter one: the programme loses its argument before it loses its budget. Two engineers are borrowed for a feature, then not returned. Nobody cancels anything, because cancelling requires a decision and drifting does not.

Quarter two: the migration is stuck in its most expensive state. A half-done move is dual-write code, two schemas, two sets of runbooks and two on-call surfaces, all carried permanently for a benefit nobody can now name. The parallel-run paths outlive the people who wrote them and become the part of the system nobody will touch, which is how a deferred migration turns into architectural debt rather than a deferred cost.

Why the programme cannot defend itself

A benefits case whose only entry is an external date has nothing to say when the date moves, and vendor dates move in both directions. Oracle's 19c support window is reported to have been extended more than once, making it an unusually long-lived release against the normal eight-year shape of five years Premier plus three Extended. A constraint owned by a third party is a planning input, not a justification, and the test is simple: if the date moved five years out, would you still do this? If the answer is no, you were never doing it for an architectural reason.

What to change this week

1. Restate the case in your own currency, with numbers. Name the specific capability the old version blocks, the licence or hosting cost it carries per year, and the hiring fact behind it. Each line needs a figure someone will defend in a budget meeting.
2. If there is no such line, stop the programme deliberately and remove the half-built state. Unwinding a dual-write path this quarter is far cheaper than maintaining it for five years. A clean stop is a legitimate outcome; a quiet stall is not.
3. Re-sequence what survives so each step stands alone. Break the 30 months into pieces that each deliver something on their own and are individually reversible, so the next date change costs you one step rather than the programme.
4. Record the constraint with its owner and its source, so the next vendor announcement arrives as news rather than as strategy.

What would have to be true for this to self-heal

Nothing. There is no mechanism that converts a date-driven programme into a value-driven one; someone has to write the benefits case. The only structural protection is the habit of refusing to fund work whose justification you do not control.

When this is the wrong answer

The security clock is real. After Extended Support ends, a release moves to a support tier with no new security patches, and if your compliance regime requires vendor-supplied fixes, the date is a hard constraint rather than a motivational device. The error is not treating a vendor date as a constraint; it is letting it be the only entry in the business case, so that the architecture argument never gets written down.