When the calendar is no longer yours: migrating under external constraint.

The migration date is set. You did not choose it. A vendor announced end of maintenance for the version you are running. Eighteen months' notice. You have spent twelve of them in evaluation mode, RFPs, and benchmarking. Six months remain. The external constraint has taken control.

Migrating under external constraint means changing discipline. You no longer migrate when you are ready. You get ready for the date. That is not the same posture, and it is rarely what project methodologies teach.

Understanding what the constraint actually changes

In a project with a free calendar, the date is a consequence of the plan. Estimate, sequence, milestone, derive a target date. If something slips, revise. The date absorbs the unforeseen.

In an externally constrained project, the date is an input. It does not move because your project slips. It does not account for the complexity of your telephony estate or your team's under-resourcing. It exists, and your plan must adapt to it.

This inversion changes everything. How you prioritise. How you sequence. Above all, how you accept — or refuse — requests to expand scope. In a free-calendar project, a new functional requirement can be accommodated by pushing the date. Under constraint, that option does not exist. You include it, defer it to a phase two, or refuse it. Refusal becomes a core project competence.

Prioritise by risk, not by functional logic

The classic trap under constraint is sequencing the project in the logical order of the final product. Start with foundations, build the main flows, add secondary features. It is an engineer's logic. It is rarely the right logic under time pressure.

Under external constraint, sequencing is done by risk. The question is not "what logically comes first?" It is "what, if not delivered on time, makes the migration impossible or dangerous?"

An inbound call flow not migrated on day one means a silent customer service. A skills database not carried over means blind routing. An unoperational recording on a regulated channel means immediate legal risk. These three items move to absolute priority, regardless of their position in the theoretical functional sequence. Everything that can wait for a phase two waits.

Under external constraint, the question is not "what do we want to deliver?" but "what can we not fail to deliver?"

Parallelise prerequisites

A sequential project waits for each step to finish before starting the next. Reasonable with time to spare. Fatal when the calendar is constrained.

Under external constraint, prerequisites must be identified early and run in parallel, even if their output is not yet required. Integration mapping cannot wait for platform selection to be finalised. Data migration cannot start after journey design is complete. Administrator training cannot begin the month before Go-Live.

Every prerequisite run in parallel frees critical path. Every prerequisite left sequential creates a cascade delay risk. In a six-month project, a two-week delay on one prerequisite can compromise the entire Go-Live.

Decisions that can no longer be deferred

External constraint has a brutal clarifying effect: it forces decisions that a free-calendar project could indefinitely defer.

Under constraint, certain decisions have a real deadline after which they can no longer be made without direct Go-Live impact. Target platform version? Recording history migration scenario? Switchover plan — progressive or total — for each flow? These decisions have a real expiry date. Past that date, the plan becomes unexecutable or risky.

The project manager's role under constraint is to make these deadlines visible, named, and assigned. Not "to be decided soon." But "the decision on recording migration strategy must be taken by the 15th, because the technical team needs two weeks to estimate volume, and that estimate conditions target infrastructure sizing." The decision has a date, a consequence if missed, and a named owner.

Refuse the comfort of the sequential

Sequential is comfortable. It gives an impression of control. Finish one thing before starting another. Wait for the right information before deciding. Take no risk on a hypothesis that might change.

Under external constraint, that comfort is dangerous. Waiting for perfect information can cost three weeks. If those three weeks lie on the critical path, they are unrecoverable. You must learn to work on hypothesis, document the hypothesis, and plan the correction mechanism if it proves wrong.

This is not improvisation. It is risk management under constraint. Take a partial decision, document it, identify what will need revision if the hypothesis changes, and move forward. Do not stop waiting for certainty. Under time constraint, certainty does not exist.

Constraint as a clarifier

After several migrations under external constraint, I have come to see these projects differently. The calendar pressure is uncomfortable. It is also, paradoxically, clarifying.

It forces acknowledgement of what is truly critical and what can wait. It drives decisions that free-calendar projects deferred indefinitely. It reveals quickly which actors can work under pressure and which need a comfortable sequential environment to progress.

The best externally constrained projects I have seen had one thing in common: a single available decision-maker with the authority to resolve trade-offs. Not a committee. A decision-maker. Someone who can say "we take hypothesis A, we document the risk, we move forward" — and who takes responsibility for the decision if it needs to be revisited.

Without that decision-maker, external constraint produces paralysis. Each team waits for someone else to decide. Validation delays accumulate. The Go-Live approaches while decisions circulate in meeting rooms.