Building a migration timeline you can hold to
Build the schedule from the cutover backwards, because the cutover hour is the only date that has a fixed relationship to everything else. Choose the moment you want live traffic arriving at the new host, then subtract each dependency in turn until you reach a start date. Plans usually slip not because a task ran long, but because a task could not begin when the plan assumed it could: a lock had not expired, a validation was still queued, or the person who signs things was away.
Count back from the hour, not forward from today
Forward planning gives you a task list and an optimistic finish. Backwards planning gives you a set of deadlines, each attached to a name. Write one line per dependency: what has to be true, by which date, and who makes it true. When two lines want the same afternoon you have found the collision four weeks early instead of at three in the morning.
The clocks other people hold
Three groups of items set their own pace no matter how much effort you apply. Put these on the calendar first and fit your own work around them.
| Dependency | Who holds the clock | Plan for |
|---|---|---|
| Transfer eligibility | Registry and registrar policy | A domain registered, transferred, or with changed registrant details recently may be ineligible for a set period. Read the date before you promise one. |
| The transfer window | Losing registrar | Several days of waiting unless you explicitly approve it sooner from the old account. |
| Domain-validated certificate | The CA, briefly | Fast, but only if your CAA policy permits that CA and you can complete the challenge. |
| Organisation-validated certificate | Human vetting | Working days, sometimes a callback to a listed number. Order this before you build anything. |
| Sign-off from another party | Their inbox | Ask in writing, with a date attached, and treat silence as a blocked task rather than a soft yes. |
Two of these deserve their own early check: the eligibility rules described in ICANN's transfer policy, which decide whether a domain transfer can even start, and the validation route for your SSL certificate, which decides whether it can be issued and installed before traffic moves rather than after.
Pick the hour from your own numbers
The conventional weekend-night slot is someone else's traffic shape. Pull hourly sessions and hourly orders for the last six to eight weeks and find your real trough. If your audience spans several regions the trough may only be forty percent below peak, and the criterion changes: choose the hour that starts your team's most alert stretch rather than the emptiest hour. Then check what runs on a schedule. Billing jobs, partner API pulls, backup windows and feed exports are invisible in session charts and very visible when they fail.
Reserve, do not pad
Slack spread thinly inside every task is consumed silently. Slack held as one owned, unallocated block gets noticed when it starts draining. A workable rule: the gap between everything ready and cutover should be at least as long as your single longest irreversible step. Use the reserve for the rehearsal described in the launch playbooks, and if you do not need it, cut over early rather than filling it.
Do not land it in front of an empty calendar
The test is simple: whoever can fix this must be reachable, awake and free for the next two working days. That rules out the evening before a holiday, the last day before someone flies, and the opening hours of a change freeze. Check the other direction too. A cutover that collides with a renewal run, a campaign launch or your seasonal peak turns a small problem into an expensive one. If no such window exists this month, move the date rather than the standard.
Still not sure which way to go?
Tell us what you are building. If it needs less than you think, we will say so.