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 safely accommodate the transition. 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 whether the schedule still has room for it.

Safety spends time. Rehearsal takes it in staging. A phased rollout takes longer because each slice has to be monitored before the next one moves forward. 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 the team on a compressed schedule gives up.

The old side stays running for about a month past the last slice, still provisioned and still costing money. A rollback path with no budget line is a sentence in a runbook.

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, even though 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 has the earliest date is running their own queue, and your migration is one item in that queue.

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 according to the contract's schedule, and access can disappear even 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 over one at a time, rehearsing 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-platforming work has to fit within 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 exposed by the move. 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 the engineer who adds it is spending the same schedule safety needs. 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 appears in a planning tool when rehearsal, observation, and the rollback reserve are entered 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.

The team that plans only around the official date crosses the earlier one unnoticed as safety mechanisms start to drop 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.

The arithmetic can also place the safe date in the past. Then the window closed before the plan existed.

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 the cost of acting early 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.