How do you migrate to Microsoft 365 without losing email?

Plan it as a project rather than a switch. Prepare the tenant and verify your domain, copy mailboxes and files in advance, run a short period where mail reaches both systems, verify everything works, then change DNS and keep the old system intact until the new one is proven. Done properly, staff notice a new login and nothing else.

Email migrations have a bad reputation because the failures are so visible: a Monday morning where nobody can send, half a team is missing three years of mail, and the phones start. Almost every one of those is a preparation failure rather than a technical one. The moving of data is well-trodden and largely automated; the things that go wrong are the ones nobody wrote down beforehand.

Preparation is genuinely the bulk of the work. Take an inventory of what exists: every mailbox including the shared and generic ones, distribution lists, calendars, contacts, and the addresses that are not people, accounts@, info@, the alias the accounting system sends from. Inventory the connected systems too, because these are what break: the practice or job-management software that emails clients, the scanner that sends PDFs to a mailbox, the website enquiry form, the accounting package issuing invoices. Each authenticates somehow and each needs reconfiguring.

Then set up the destination before touching anything live. Verify the domain, build the users and groups, apply the security settings you want from day one rather than retrofitting them later, and configure multi-factor authentication with a plan for enrolling everyone. Getting security right at this moment is much cheaper than adding it to a running tenant, which is the pattern we followed at Adelaide City General Practice, where Microsoft 365 and DUO multi-factor authentication went in as part of the same project rather than as an afterthought.

Copying comes next, and the sequencing is what protects you. Bulk-copy mailboxes and files while the old system is still live and in use, which takes as long as it takes without anyone waiting. Then, at cutover, only the delta since the bulk copy needs to move, which turns a potentially day-long operation into a short one. Cutover itself is a DNS change pointing mail at the new tenant, and it should happen outside business hours with the old system left running, because DNS propagates unevenly and mail may arrive at either place for a while.

Verification is the step most often skipped, and it deserves a written checklist ticked by a person. Can everyone send and receive, internally and externally? Do the shared mailboxes and distribution lists work? Has every connected system been tested by actually sending something through it? Are calendars and contacts intact? Is mobile mail working? Test the awkward ones specifically, the scanner, the invoicing system, the enquiry form, because those fail silently: nobody reports the enquiries that never arrived.

Keep the old system for a while. A month is a reasonable default, longer if your record-keeping obligations suggest it. It costs a little and it is your rollback path, plus it is where the item nobody remembered turns out to live. Decommission deliberately when you are confident: export what you must retain, document what was destroyed and when, and cancel the service rather than letting it lapse and take the data with it.

Tell staff what is happening and when, in plain terms, before it happens. The single biggest source of migration-day support calls is not technical failure but people encountering an unexpected sign-in prompt and assuming something is broken or, worse, that it is a phishing attempt. A short note covering what will change, when, what the new sign-in looks like and who to call converts most of those calls into nothing at all.

The honest caveats. Very large mailboxes and slow internet connections extend the copying, so measure rather than assume. Old on-premise mail servers occasionally hold surprises that only surface mid-migration. And migration is the right moment to fix the things you have tolerated, the shared logins, the mailbox everyone knows the password to, because moving them faithfully into a new system just carries the problem across. The measure of a good migration is boring: staff sign in on Monday, everything is where they left it, and nobody has a story to tell about it afterwards. If you want it planned and cut over cleanly, call 1800 456 567.