Migrating company email to Microsoft 365 looks like a Saturday-afternoon job for the IT person. In a 25-person company it's actually a three-week project with two real moments where you can lose your whole team a week of work. The good news: if you plan it properly, your users won't notice the switch — except that Outlook now searches for an email in a second instead of thirty.
Earlier this year we ran one of these migrations for a 25-person distributor of industrial parts. The old mail server lived in the basement, ran on Exchange 2013, hosted 142 GB of mailboxes, and had just announced it was losing vendor support in six months. Replacing the hardware and licenses came out around 28,000 PLN, with no ransomware resilience and no usable mobile access. After moving to Microsoft 365 Business Standard (25 licenses × 56 PLN/month net, i.e. 16,800 PLN/year) they also got OneDrive and Teams at the same price. The migration took 19 calendar days, the MX cutover ran for 4 hours on a Saturday night, and on Monday morning the sales team only noticed that their phone email "configured itself". Lost messages: zero.
Below is the skeleton for getting your company to that last sentence.
What to inventory before you start
Most migration problems share one root cause: nobody knew what was actually sitting in the old system. The first week isn't really "migration" — it's stocktaking.
- Mailboxes and their sizes. Not just active staff — also shared mailboxes (
office@,service@), aliases, and ex-employees whose mailbox someone still reads "just in case". A 25-person company typically ends up with 35–50 objects. - Rules, signatures, auto-replies. Server-side rules vanish overnight if no one rebuilds them. This is exactly the moment when accounting stops getting CC'd on invoices because the rule "forward a copy to accounts" lived on the old server.
- Distribution lists and groups. In Exchange they're objects, but in hosted IMAP they're often just an alias arrangement at the provider. They have to be written down on paper because nothing exports them.
- SMTP integrations. ERP, e-commerce, multifunction printers, cameras, alarm system — anything that sends mail from your domain. The list is always longer than anyone remembers. That's where most of the "weird Monday errors" come from.
- DNS records. MX, SPF, DKIM, DMARC, autodiscover, sometimes a legacy
_imap._tcp. Take a snapshot before touching anything. For Polish clients we almost always see SPF stuffed with ten old providers nobody sends through anymore.
This stage isn't glamorous, but it's where 80% of the surprises get filtered out. Without it, the MX cutover is a jump without a rope.
How to move the data without downtime
Microsoft 365 offers three real migration paths, depending on where you're coming from:
- Cutover migration (on-prem Exchange, up to 100 mailboxes). The simplest option for a small company with local Exchange. M365 pulls the mailboxes itself over Outlook Anywhere, and you flip MX when it's done. The official limit is 2000 mailboxes; for a 25-person company it happens in one sweep.
- IMAP migration (hosted mail like home.pl, OVH, cPanel). M365 connects as an IMAP client and copies the Inbox and subfolders. What doesn't come across: calendars, contacts, rules, and in some configurations even "Sent". Those have to be rebuilt manually or with helper tools (
PST). - PST-based migration. The least elegant but universal one. You export each mailbox to a PST file and upload it to M365 via Azure Storage. Always works, but leaves the user with a week-long gap between "this morning" and "this evening" unless you do it incrementally.
For the 25-person Exchange company we chose cutover. For a 12-person accounting firm with hosted IMAP — IMAP migration plus PST for calendars. In both cases the key is migrating in two waves: the first copies everything except the last 24 hours; the second (on cutover night) catches up the tail. That way you're not copying 142 GB on Saturday evening — you're copying 80–200 MB.
The MX cutover — the moment of truth
This is when the world flips over. From experience: do it Saturday night between 22:00 and 02:00, never Friday night, because DNS TTLs that crawl through Polish telco resolvers rarely settle before the Monday morning shift.
Step by step on cutover night:
- Drop the MX record TTL to 300 seconds, ideally 24 hours in advance. Without that, some providers will keep routing mail to your old server for another day.
- Stop the queue on the old server and wait 5 minutes for it to finish processing whatever just arrived.
- Run the delta sync in M365 — the second wave that pulls the last day in.
- **Switch MX to
.mail.protection.outlook.comand update SPF and DMARC at the same time*. SPF must containinclude:spf.protection.outlook.com, otherwise everything you send starts landing in spam at your German partners. - Leave the old server running as a receiver for 72 hours. Some old SPF and MX caches at your partners won't refresh until Monday. The old server in receive-only mode with a forwarder to M365 catches those stragglers.
- Repoint printers, ERP and SMTP integrations to the new host (
smtp.office365.comwith a technical account and app password, or better, an M365 connector with IP-based authorization).
That last point is where most projects stub their toe after go-live. Multifunction printers that have been scanning to email without authentication for five years won't send anything through M365 until someone creates a technical account with an app password or configures an IP connector. That's 30 minutes of work if you remember to do it — or half a day of Monday-morning panic if you don't.
What to check on the first Monday
The first 48 hours after the switch is not a time for lunch. Hold a checklist and tick items off:
- Send and receive tests from three external accounts (Gmail, one O365 partner, one Polish-hosted partner). Verify mail doesn't land in spam at the other end — keep DMARC at
p=quarantineinstead ofp=rejectfor the first week if you're cautious. - Rules, auto-replies, signatures for every user — pull the list from the old server and walk through person by person.
- SMTP integrations. Did the ERP send the PDF invoice? Did the printer scan-to-email? Did the shop send order confirmations? Every "no" needs handling that same day.
- Mobile clients. Outlook on iOS/Android should pick the new account up automatically through autodiscover. Sample five random users and confirm.
- Shared mailboxes and delegations. "The assistant had access to the owner's mailbox" — that's a separate configuration that needs to be rebuilt by hand.
Plan the first M365 mailbox backup the same week. Microsoft keeps your mail on their servers, but they don't back you up against a deletion you discover six months later. That's a separate decision and a separate cost (see our post on backing up Microsoft 365 for SMEs).
What next
Email migration to Microsoft 365 in an SME isn't technically complex. But it's unforgiving about the mess that usually lives in DNS records, server-side rules and SMTP integrations. If someone sells you a "weekend switchover with no plan", that's not what you need — you need two weeks of inventorying and one night of cutover.
If you're planning a move to Microsoft 365 in the next few months, or you're stuck mid-migration — let's talk. The first call is free and takes half an hour. It's usually enough to point out where the biggest risks in your setup are before anyone touches MX.
The Microsoft 365 migration isn't finished when MX flips — it's finished when the printer, the ERP and the shop send mail the same way they did on Friday evening.