Your safe migration window closes before the deadline

Two deadlines govern a forced transition. The official one is the end-of-life date or the contract's final day. The real one is unmarked and arrives earlier, on the last day the schedule can still afford to run the transition safely. That is when the safe migration window closes.

Migration safety has its own time budget

Migrate early or migrate late, and roughly the same systems have to move—the same services and data, the same dependencies repointed at something new. What timing decides is what the schedule still has room for.

Safety spends time. Rehearsal takes it in staging. A phased rollout takes more, because each slice has to be watched before the next one moves. Rollback needs its own reserve. A way back is only real while the old path stays warm and there's still time to use it. Each of these exists so the migration can stop the moment a number looks wrong, and stopping is the first thing a compressed schedule gives up.

Wait, and the safety mechanisms compete with delivery for what remains. Which one gets shortened depends on the system. Staging may be skipped, phases merged, or rollback left in the runbook after the schedule can no longer afford it. The migration can still fit on the calendar after its safety no longer does.

A late migration also answers to other people's queues: the incoming vendor's onboarding backlog, the auditor's date. Whoever holds the earliest date is running their own queue, and your migration is one item in it.

The asymmetry is control. Acting on a real signal lets you choose the commitment. Move inevitable work forward or buy a scoped option you may never use. React late and external constraints start choosing the commitment. The early move works only if the destination has settled. Jump to a target that's still shifting, and you migrate twice, both times against a deadline. Read the signal hard before you commit.

Access and support expire on schedules you don't set

A vendor exit ends your access on the contract's schedule, and access can disappear while the outgoing platform remains healthy. The move off it is ordinary work while both platforms still answer. Clone the repositories with full history, rebuild the pipelines, cut the integrations one at a time, and rehearse each step against a system that still exists.

When an OS reaches end-of-life, it loses support, and so does everything coupled to it. When the platform running the workloads exists only on the old OS, the OS deadline becomes a re-platforming date, and the re-platform is the work that has to fit inside the window. Started months ahead, it ships a slice at a time, each slice observed before the next. Pushed into the final weeks, the same re-platform compresses observation and makes the fallback harder to preserve.

An early migration leaves room for adjacent improvements

Once rehearsal, observation, and rollback are locked into the plan, an early migration may still have room to remove duplication that the move exposed. A platform exit can merge two toolchains while their repositories and pipelines are already changing. A replacement platform can also remove a constraint imposed by the old one.

The improvement still adds scope, and scope competes for the same schedule as safety. If it pushes the plan past the safe deadline, leave it out. The transition stays an opportunity only while its observation and rollback reserves are intact.

The safe deadline is arithmetic

The safe deadline only shows up in a planning tool when rehearsal, observation, and the rollback reserve go in as scheduled work items. Leave them as implied slack, and the plan spends them without showing it. The estimate itself is backward arithmetic from the official date: the rollback reserve you'd want if the last slice misbehaves, the observation each slice needs before the next ships, the rehearsal runs, the room to stop on the first wrong number. The durations are ranges. In a phased migration, the safe date can land months before the official one.

A plan built only around the official date crosses the earlier one unnoticed, as safety mechanisms start dropping out to make the calendar work. Build the plan around the earlier date and the missing time becomes visible while scope, sequencing, and the destination itself are still choices.

Only real windows deserve early action

None of this means chase every signal the day it shows up. Treat every signal as a deadline and speculative transitions consume the capacity reserved for real ones.

First, is the window real? A hard end-of-life date, or a contract with a defined end, is real and dated; you can look up when it lands. Rumored acquisitions and tentative deprecations belong in the signal column. Their dates are still unknown, so weigh what acting early costs against what it protects.

Then ask what would strand you. If the window closed tomorrow, what would become unrecoverable? Protect that first, and spend the least that makes the worst case survivable.

The full migration can wait. The part that becomes unreachable when access, support, or the old system disappears cannot.