Most practices move to Microsoft 365 for a good reason: an ageing mail server in a cupboard is both the largest security exposure and the largest single hardware risk a small practice tends to carry. When that box dies, email stops, and email stopping is not survivable for a day.
The move itself is routine when planned and genuinely painful when not. Two things go wrong, and they go wrong in different places.
Part one: moving without losing a morning
Work out what actually has to move
This is the step that gets rushed. Before anything else, inventory the lot: every mailbox and its size, shared mailboxes like info@ or billing@, resource calendars for rooms and equipment, distribution lists, contacts, any public folders, and the file shares with their permissions.
Practices are always surprised by something here. A referrals mailbox nobody has logged into since 2019 but which still receives. A calendar the front desk relies on that nobody realised was attached to a departed employee's account.
Pick an approach that suits the size
A small practice with a handful of mailboxes can usually move in a single cutover over a weekend: everything copies across, mail flow switches on Saturday, Monday morning is on the new system. Simple, and there is one moment of risk.
A larger practice moves in batches, a few users at a time, so there is never a point where the whole organisation is mid-migration. It takes longer and each individual step is lower risk.
Either way there is a pilot group first: two or three people who are comfortable telling you when something is odd, moved a week ahead of everyone else.
The part that causes the visible failures
Mail routing is controlled by DNS records, and DNS changes take time to propagate. The mistake is flipping the record before mailboxes have finished syncing, which sends new mail to a destination that is not ready for it.
The old system stays reachable and able to receive until the new one is verified. Then mail flow cuts over deliberately. Then the old system stays running, silent, for a couple of weeks, because that is when you find the scanner that was configured to send through it in 2018 and that nobody remembered.
Part two: the configuration that gets skipped
The migration works, everyone gets their mail, and the project is declared finished. This is where most practices stop, and it is the point at which three things should happen and usually do not.
1. Multi-factor authentication, on everybody
This is the single highest-value thing available to a small practice and it gets deferred because it feels like friction. Configured sensibly it is one approval on a trusted device, not a prompt every hour.
The thing to understand is what it prevents. Business email compromise, where somebody gets into a mailbox and quietly watches, is one of the more expensive events that happens to small organisations. The attacker reads the mail, learns how invoices are handled, and at the right moment sends a convincing message redirecting a payment. A stolen password alone is enough for that. A stolen password plus MFA usually is not.
2. Alerting on the fingerprints of a compromise
The tell for the attack above is a mailbox rule: one that quietly forwards incoming mail to an outside address, or files certain messages straight into a folder nobody checks so the real invoice is never seen.
Microsoft 365 can alert when such a rule is created. It is off by default. Switching it on takes minutes and is the difference between noticing in an hour and noticing when a payment goes missing.
3. Backup, which Microsoft does not do for you in the way people assume
This is the most common misunderstanding in the entire subject, and it is worth being precise about.
Microsoft runs the service and keeps it available. They are explicit in their own documentation that protecting your data within it is your responsibility. There is limited retention: a deleted item sits in a recoverable folder for a period, and then it does not.
So if a staff member deletes a folder and nobody notices for three months, or a departing employee empties their own mailbox, or ransomware encrypts a synced document library, the platform's own recovery window may well have closed. Independent backup of cloud mail and files closes that gap, and for a practice with retention obligations it is not optional.
What healthcare practices specifically need to sort out
Beyond the above, there are a few items particular to a practice.
- A Business Associate Agreement with Microsoft, which is available and which somebody needs to actually have accepted rather than assumed.
- A decision about how anything containing patient information is sent. Either an encryption mechanism on the platform, a portal, or a clear policy that it does not go by email at all. Pick one deliberately.
- Audit logging turned on and its retention understood, so there is a trail if anyone asks.
- Licence review. Practices routinely pay for a higher tier than they use, or for seats belonging to people who left. It is common for this to fund a meaningful share of the migration itself.
Microsoft 365 or Google Workspace
Usually whichever your clinical software expects. Practice management, billing and imaging vendors overwhelmingly build around Office formats and Outlook, and fighting that costs more than it saves. If your team already lives in Google tools and your clinical vendors are happy, moving them has a real cost and little benefit.
We have no preference to sell you. We will ask what your software expects and recommend the one that causes fewer arguments.
- Microsoft 365
- Healthcare