Insights / Article / Cloud migration and infrastructure evaluation
ArticlePlanning a calm migration weekend
A calm cut-over is built long before the weekend itself: on rehearsal, clear roles and a tested way back.
Most system migrations end in a single concentrated window, often a weekend, when the old system is switched off, data is moved and the new environment goes live. For the people involved, it can be one of the most stressful periods of the whole programme. For the business, it is the moment when months of work either land smoothly or create a difficult week.
The difference between a calm cut-over and a chaotic one is rarely luck. A calm cut-over is built on rehearsal, clear roles and a tested way back. Almost all of that work happens in the weeks before the weekend, not during it.
Rehearse until it is boring
Practise the steps and timing in advance. A full rehearsal, using recent copies of production data and following the real runbook, reveals the problems that a plan on paper hides: a script that takes four hours instead of one, a permission that was never granted, a step that depends on someone who will not be available.
- Run at least one full dress rehearsal, and more for complex or high-risk migrations.
- Time every step and compare against the plan; adjust the schedule to real durations.
- Use the same people who will do the real cut-over, so they know the steps.
- Record every problem, fix it and update the runbook before the next rehearsal.
- Aim for a final rehearsal that runs cleanly, within time, with no surprises.
A rehearsal that goes wrong is a success: it found a problem cheaply. The aim is a final run so predictable that the real weekend feels like a repeat.
Write a runbook people can follow at 3 a.m.
The runbook is the step-by-step script for the cut-over. It should be detailed enough that a tired person can follow it in the middle of the night without improvising. Each step has a number, an owner, an expected duration, a clear completion check and the next step to move to.
Include checkpoints where the team pauses to confirm everything is on track before continuing. Note dependencies explicitly, so nobody starts a step before its predecessor is confirmed. Keep contact details for every person and supplier involved at the front, including out-of-hours numbers.
An example timeline
Consider a typical mid-sized distributor moving its finance and order systems over a weekend. The old system is frozen at 6 p.m. on Friday after the last orders are shipped. Data extraction and loading run overnight, with a reconciliation checkpoint at 8 a.m. on Saturday. Integrations and user access are configured during Saturday, followed by business testing of key transactions. The go-live decision is taken at a fixed checkpoint on Sunday morning, which leaves Sunday afternoon either to finish set-up or to roll back calmly. Every one of those times was proved in rehearsal, not estimated.
Assign roles and decision rights
Everyone should know their task and who decides to proceed. Confusion over authority is one of the commonest causes of delay during a cut-over: the team hits a problem, and nobody is sure who can decide whether to carry on, wait or roll back.
- Cut-over lead: runs the plan, tracks progress against the runbook and coordinates the team.
- Decision owner: a senior business sponsor who makes the go or no-go calls at each checkpoint.
- Technical leads: own specific steps such as data migration, infrastructure, integrations and security.
- Business validators: check key data and transactions in the new system before sign-off.
- Communications owner: keeps stakeholders, users and suppliers informed on an agreed schedule.
Agree go or no-go criteria in advance
Before the weekend, write down what must be true at each checkpoint to continue: reconciliations within tolerance, key transactions tested, no critical defects open. Decisions made against criteria agreed in daylight are far better than decisions made under pressure at midnight.
Prepare to roll back
Define the point of no return and the way back before you start. Every migration should have a tested rollback plan: the steps to return to the old system if the new one cannot go live safely. The plan should be rehearsed as seriously as the migration itself.
The point of no return is the moment after which rolling back becomes impractical, usually because new transactions have started in the new system or the old system has been changed. Know exactly where it falls in the runbook. Before reaching it, the decision owner should explicitly confirm that the go-live criteria are met.
- Keep the old system intact and available until the point of no return has passed.
- Take verified backups of both source and target at defined points.
- Time the rollback steps during rehearsal, so you know how long a return would take.
- Set a latest time for a rollback decision that still allows the business to open normally on Monday.
Communicate on a schedule
Stakeholders who hear nothing assume the worst. Agree in advance who receives updates, how and when: for example, short messages to the sponsor group at each checkpoint and a summary to all users when the system is live. Tell suppliers, customers and partners about any downtime well before the weekend, and confirm on Sunday evening that normal service will resume.
Keep a single written log of decisions and issues throughout the weekend. It helps the team hand over between shifts, and it gives you an accurate record for the review afterwards, when memories of the night will already be hazy.
Plan Monday morning too
The weekend ends, but the cut-over does not. The first working day is when real users meet the new system at volume. Plan for it: extra support staff on site and on the phones, champions in each team, a quick route for reporting problems and a short daily review for the first week to triage issues. A typical pattern is a burst of small questions in the first two days that falls away quickly when support is visible and responsive.
Begin by booking the dress rehearsal dates and naming the decision owner. Those two commitments shape everything else, and they are the ones most often left too late.
Source: Intelliversal analysis.
