Module 3 · 3.3

English

Nederlands English Deutsch Français Español

A migration plan: order, risks and fallback

Module 3: Taking stock and planning · Reading time: 12 minutes

Learning objective: After this lesson, you'll be able to draw up a migration plan with phases in the right order, a risk list, a go/no-go moment and a fallback plan.

Key concepts: migration plan, phase, pilot, big bang, phased switch, dependency, TTL, freeze moment, transition period, risk list (likelihood and impact), go/no-go, fallback plan (rollback), cancelling

Why a plan?

With your inventory (lesson 3.1) and your figures (lesson 3.2) you know what needs to happen. A migration plan states in what order, when, by whom, and what you do if something goes wrong. It prevents the two classic mistakes: doing things in the wrong order (switching the MX before the new mailboxes exist) and cancelling the old service too soon.

Big bang or phased?

There are two main routes.

Route	What it is	Suitable for	Risk
Big bang	Everything switches over at one moment, for example over a weekend	Small organisations with few integrations	If something goes wrong, it goes wrong everywhere at once
Phased	Switching over per component or per group of people, spread over several weeks	Larger organisations or many integrations	Two systems running side by side for a while; people get confused

For most small organisations, a phased switch per component works well: first files, then calendar and contacts, then mail, then the rest. Mail as a single switch for everyone at once, because the domain can only point to one place at a time.

Always start with a pilot: one or two people who already do everything in the new service, for a week or two. They find the problems, and you adjust the plan before the rest follows.

The phases

A migration has five phases.

1. Preparing

Inventory and figures complete (lessons 3.1 and 3.2).
New service chosen, contract and data processing agreement signed (lessons 2.4, 9.2).
Export or backup of everything from the old service, before you change anything. This is your safety net.
Tidied up what can go.
Users and admins created in the new service, two-factor authentication switched on (lesson 7.3).
The TTL of your MX records lowered, for example to 300 seconds. Do this at least one old TTL period before the switch. If the TTL was 86400 seconds (one day), lower it at least a day in advance (DNS course lessons 6.1 and 6.3).

2. Pilot

One or two people switch over.
You test the trickiest documents, the phone apps, the integrations.
You write the cheat sheet and the explanation for the rest (lesson 9.1).

3. Transferring

Copy files; set up folders and shares again (lessons 6.1, 6.2).
Export and import calendars and contacts (lessons 5.2, 5.3).
Copy mailboxes for the first time, while the old mailbox still receives mail as normal (lesson 4.2).
Switch over integrations: website, scanner, till system, software.

4. Transition

At the agreed moment: switch the MX records, update SPF, DKIM and DMARC (lesson 4.3).
Shortly after, and again a day later: copy the mailboxes once more, so that mail that arrived at the old service in the meantime is still brought across (lesson 4.4).
Switch over everyone's devices; turn off old sync apps (lesson 7.2).
A freeze moment for files: from that point on, no one works in the old storage any more.

5. Wrapping up

Check: count folders, files, appointments, contacts and mail.
Let both run side by side for a few weeks, with the old one read-only if possible.
Only then cancel the old service, and ask for confirmation that your data there will be deleted (lesson 9.3).
Update the record of processing activities and the privacy notice (lesson 9.3).

The dependencies you must not reverse

Some steps really must happen one after the other. These are the hard rules:

Export or backup of the old service comes before any change.
The pilot comes before the rollout to everyone.
The mailboxes in the new service exist before you switch the MX. Otherwise the new server refuses the mail.
The TTL has been lowered at least one old TTL period before the MX switch.
The first copy of the mail is made before the MX switch; the second copy after the MX switch.
The calendars have been imported before you link the phones. Otherwise the phone syncs halfway through an import and you get duplicates.
The old service is cancelled last, after the check.

Exercise A3.3 lets you put this order together yourself and checks it.

Risks: likelihood times impact

A risk list sets out what could go wrong, how likely that is and how bad it would be. Score likelihood and impact, for example, from 1 to 3 and multiply them. Anything with a score of 6 or 9 gets a measure.

Risk	Likelihood	Impact	Score	Measure
Mail doesn't arrive during the switch	2	3	6	Lower TTL in advance, switch outside peak hours, second sync
Documents with macros don't work	3	2	6	Test set in the pilot (lesson 6.5), temporarily keep Excel running alongside
Colleagues keep working in the old storage	3	2	6	Freeze moment, old storage read-only, explanation
Phone shows everything twice	2	1	2	Import first, then link; turn off the old account
Till system stops working after accounts are closed	2	3	6	Own login before closing accounts (lesson 2.3)
Old service contract renews automatically	2	2	4	Cancellation date in the calendar

Go/no-go and fallback plan

Agree in advance who decides at the moment of the MX switch, and on what basis. A go/no-go moment with a short checklist: all mailboxes created and tested, first copy done, TTL low, pilot without major problems, colleagues informed. If even one of those points isn't green: don't go ahead, and choose a new date. It feels like failure, but it's exactly what the moment is there for.

A fallback plan (rollback) describes how you go back if things still go wrong after the switch. For mail, this is relatively simple as long as the old service still exists: switch the MX records back to the old values (which you wrote down beforehand, or for which you made a DNS backup), and copy back the mail that arrived at the new service in the meantime. This is only possible if you haven't cancelled the old service yet. That's why you cancel it last.

Planning over time

An example for the bakery, with twelve people:

Week	What
1	Inventory, figures, choice, contract; export from old service
2	Create users, 2FA, pilot with two people; lower TTL at the end of the week
3	Transfer files and calendars; first mail copy; switch over integrations
4	Early Monday morning: MX switch; second copy the same day and on Tuesday; switch over devices
5	Checking, question hours
6 to 8	Both running side by side; then cancel old service, update the register

Choose the moment of the switch deliberately. Not right before a busy period (for a bakery, not the week before the festive holidays), not when the administrator is going on holiday, and with time to solve problems the following day.

In practice: what it looks like with a provider

The WebOké Nextcloud guide gives a fixed order: first create users and secure the account, then files, then calendars and contacts, only then the apps, and only cancel the old service once everything is confirmed to be in order. For mail, the Email migration tool works with a first copy before and a second copy after the MX switch. Other European providers advise much the same order, because it follows from how mail and synchronisation work.

Summary

A migration plan sets out order, timing, responsibilities and fallback.
Phased by component, with a pilot beforehand, works for most small organisations; mail switches over for everyone at the same time.
Hard order: export first, pilot before rollout, mailboxes and a low TTL before the MX switch, second copy afterwards, import before linking, cancel last.
A risk list with likelihood and impact shows where you need measures.
A go/no-go moment and a fallback plan make it safe to say "not yet" too.

Quiz

Exercise

Exercise A3.3: Put the steps in the right order. You're given eighteen steps of a migration in a random order. Put them in an order that works. The programme checks the hard rules from this lesson and tells you exactly which rule you're breaking.

Exercise A3.3: Put the steps in the right order

For each slot, choose which step belongs there (each step exactly once), fill in the old TTL of your MX records and the times at which you lower the TTL (step "Lower the TTL") and switch over the MX. Times as dd-mm-yyyy hh:mm. The system checks your order against eleven hard rules.

Step 1

Step 2

Step 3

Step 4

Step 5

Step 6

Step 7

Step 8

Step 9

Step 10

Step 11

Step 12

Step 13

Step 14

Step 15

Step 16

Step 17

Step 18

Old TTL of the MX records in seconds (for example 3600)

When do you lower the TTL? (dd-mm-yyyy hh:mm)

When do you switch over the MX? (dd-mm-yyyy hh:mm)

What you enter and what we find isn't stored. Your browser remembers your answers and whether you've passed the exercise. If you're signed in, we only save that you got the exercise (almost) right in My courses; you can delete that there too.

Exercise E3.3: Your own migration plan. Use the template to create a migration plan for your own organisation: phases with dates, people responsible, a risk list with at least five risks, a go/no-go checklist and a fallback plan.

Exercise E3.3: Your own migration plan

Fill in the template based on your inventory (A3.1/E3.1) and your figures (E3.2), and have one colleague read it.

Each phase has a date or week and someone responsible.
The strict order from A3.3 is correct in my plan.
The TTL reduction is at least one old TTL before the MX switch.
There's a risk list with at least five risks, with likelihood, impact and measure.
There's a go/no-go checklist and I know who decides.
There's a fallback plan, with the old MX values written down.
The cancellation date of the old service is after the check and within the contract's notice period.
A colleague has read the plan.

What's the biggest risk in your plan, and what will you do if it happens anyway? (at least 3 sentences)

Your ticks and notes only stay in this browser; we don't send them anywhere. If you're signed in, we only save in My courses that you've done the exercise.

Cookies at WebOké

Cookie settings

Necessary

Marketing