3 September 2026LANTEK Computers
A migration to Microsoft 365 is a well understood project. It goes wrong in predictable places, and almost none of them are the mail.
This is about moving the platform. If you are also changing IT provider at the same time, do not: sequence them, and changing provider covers that separately.
Before anything moves
Establish who owns the domain
You cannot do this properly without administrative access to your own domain’s DNS, because mail delivery is redirected by changing records there. If somebody else holds it, resolve that first. It is also the single most important thing to own regardless of any migration.
Find out how much data there actually is
Not an estimate. The real figure for mailboxes and for file shares. This governs the timeline more than anything else, because moving data has a floor set by your connection speed, and a business that assumes a weekend and discovers it needs five days has a problem that is arithmetic rather than technical.
Two things routinely inflate the number: mailboxes with years of history nobody has ever archived, and a file share containing every version of every document since 2011.
Decide what is not coming
This is the opportunity people waste. A migration is the only time anybody will sanction going through the shared drive.
Departed staff’s mailboxes, folders untouched for a decade, the fifteen copies of the same file with different suffixes. Deciding what to archive rather than migrate shortens the project, reduces what you pay to store, and reduces what you would have to assess in a future breach. Note archive rather than delete: keep it somewhere cheap and out of the way, because deleting in a hurry during a project is how something important goes.
Inventory what depends on the current setup
The list that catches people. Anything that sends mail without a person doing it:
- The scanner or multifunction printer that emails documents
- The accounting package that emails invoices and statements
- The website contact form
- The alarm or monitoring system that sends notifications
- The payroll system that sends payslips
- Any application with an SMTP setting somebody configured once
Each of these has to be reconfigured, and each is discovered on the Monday after if it is not found before. Walk round and check every device that has ever emailed anybody.
The order that keeps people working
One. Set up the tenant and prove identity works. Accounts created, licences assigned, multi-factor authentication configured, and a small group signing in successfully. Nothing has moved yet.
Two. Pilot with a handful of real people. Not IT. A few staff doing normal work, including somebody who uses it heavily and somebody who finds computers difficult. The second person will find things the first will not.
Three. Pre-seed the data. Copy mailboxes and files across in the background, over days, while everybody carries on working on the old system. This is what removes the weekend crunch: by cutover, almost everything is already there and only the recent changes need syncing.
Four. Move mail, out of hours, in groups. Department by department rather than everybody at once. If something is wrong you have affected eight people, not eighty, and you learn before the rest.
Five. Move files, separately and later. Not the same weekend as mail. Give yourself a working week between them.
Six. Reconfigure the devices and applications from the list above. Test each one by actually sending something and confirming it arrives.
Seven. Leave the old system running, reachable but not receiving. For a few weeks. It costs a little and it is what you fall back on.
Eight. Decommission, deliberately, once nothing has referenced it for a month.
What genuinely interrupts people, and for how long
Being straight about this is better than promising seamless.
Mail clients reconfigure. Each person spends part of a morning signing in and waiting for a mailbox to populate. Unavoidable, universal, and best done as a scheduled exercise with somebody walking the floor.
Multi-factor enrolment. Everybody registers their phone once. Do it in a session, in person, because the enrolment is the fiddly part and doing it at forty desks individually takes longer than doing it in a room.
Mapped drives change. The letter people have used for years becomes something else. Expect a fortnight of small confusion and consider keeping the familiar path via a shortcut rather than insisting people relearn.
Shared mailboxes and calendar permissions. These are always more tangled than documented, and they break in ways nobody predicted. Ask, before the move, who has access to whose calendar.
The one application with a hard-coded mail server. There is usually one, and its vendor is slow. Find it early.
Things worth doing while you are in there
The migration is the cheapest moment to set these, because everything is being touched anyway.
Multi-factor authentication from day one, so it is never a separate rollout with its own resistance. Access on file areas that reflects who should see what, rather than replicating whatever the old share had. A retention decision, so mail is not kept forever by accident. And a third party backup of the tenant, because Microsoft protects the service rather than your content, which is the argument in Microsoft 365 is not a backup.
That last one gets deferred and then forgotten. Do it during the project.
Two questions to ask whoever is quoting
How much data are you moving, and how long will that take on our connection? A provider who has not measured it is guessing at your timeline.
What is the fallback if the mail cutover goes badly? There should be one and it should be describable. Any answer that amounts to it will be fine is not a plan.
The reason this is worth doing here specifically
Beyond the usual arguments, there is a South African one: a business whose mail lives on a server in the office loses access to mail whenever the office loses power. A business whose mail is hosted does not. That is covered in what load shedding does to your data, and for many businesses here it is the argument that actually decides it.
What we cover is on Cloud Computing. If you want to know how big your migration actually is before committing to anything, ask us to measure it. The data volume is the answer to most of the questions you have.