A move to Microsoft 365 is often postponed out of fear of lost mail, broken calendars or a day of standstill. Understandable — but unnecessary. How migrating to Microsoft 365 without downtime works is not a matter of luck but of a playbook: take stock, run a pilot, synchronise in advance and only switch over once everything is tested. In this article we walk through the whole process in seven phases, including the pitfalls that make most migrations stumble. Would you rather hand it over? See how we approach a Microsoft 365 migration without downtime.
How migrating to Microsoft 365 really works
A migration is not a copy-paste job but a move with a plan. You are relocating not only mail, but also calendars, contacts, shared mailboxes, files, users and the permissions attached to them — all while your team keeps working. The art is not in the transfer itself, but in the sequence and the timing around it.
The common thread in migrating without downtime is simple: move as much data as possible in advance while the old system is still running, test thoroughly on a small group, and only switch over the final piece (the mail flow) at a quiet moment with a fallback option at hand. No big bang you can't back out of.
Still torn between Microsoft 365 and Google Workspace? Then first read Google Workspace vs Microsoft 365 — an honest comparison helps prevent you having to move the other way again a year from now.
The step-by-step plan in 7 phases
Below is the approach that, in practice, makes the difference between a smooth switch and a chaotic Monday morning. Each phase builds on the previous one; skip one and you usually pay for it in the cutover phase.
- 1. Inventory & licences — Map out what you have: number of users, mailbox sizes, shared and functional mailboxes, distribution lists, Drives/shares, integrations (accounting, CRM, scanners) and existing forwarding rules. Based on that, choose the right Microsoft 365 plan per user group — not everyone needs the same licence.
- 2. Migration plan & communication — Set out what moves in which order, who gets migrated when and what your team needs to do (think of signing in again on phones). One clear email in advance prevents ten panicked phone calls afterwards.
- 3. Prepare the tenant & environment — Set up the Microsoft 365 tenant: verify the domain (still without switching the mail DNS over), users, groups, SharePoint/Teams structure, security (MFA) and admin rights. The tenant is ready, the old environment stays live.
- 4. Pilot with a test group — First migrate a small, representative group (5 to 10 people, including someone with a shared mailbox). Check mail, calendar, contacts, permissions and integrations. This is where you catch problems while they are still small and cheap.
- 5. Migrate data (mail, calendar, contacts, files) — Move the bulk while the old system keeps running. Mail and files are synchronised in advance, so everything is already in place in Microsoft 365 before the actual switch-over.
- 6. Cutover & DNS switch outside working hours — At a quiet moment (evening or weekend) you switch the MX records so new mail flows to Microsoft 365. A final delta sync retrieves the mail that came in in the meantime. No one is working at that moment, no one misses anything.
- 7. Aftercare & clean-up — In the days that follow: support for your team, checking forwarding rules and aliases, phasing out old licences and only cancelling the legacy environment once everything is confirmed 100% up and running.
How to prevent downtime and data loss
Downtime almost never comes from the migration itself, but from poor timing of the DNS switch. The solution lies in two principles.
Synchronise in advance. By moving mail and files while the old system is still running, all you need to do during the cutover is retrieve the last remnant (the delta). The heavy copying job is long behind you by then — the actual switch-over takes minutes, not hours.
Keep a fallback option. Until the migration is definitively confirmed, the old environment stays available as a safety net. If something unexpectedly goes wrong, you can go back. A migration should be reversible up to the moment you are certain everything is correct. That is exactly why the DNS switch happens outside working hours: if something doesn't go as expected, you have the calm to adjust before everyone gets back to work.
The pitfalls that make migrations stumble
Most failed switches run aground not on ordinary mailboxes, but on the edge cases. In your inventory, pay extra attention to these points:
- Shared and functional mailboxes (info@, sales@, invoices@) — these work differently in Microsoft 365 than in Google Workspace. Forget them and an entire department can suddenly no longer access the shared mail.
- Permissions and access — moving files is easy, bringing the right access permissions along is the real work. Without that, no one may be able to reach the right folders after the switch.
- Forwarding rules and aliases — hidden forwards and filters are often forgotten and cause lost or duplicated mail after the migration.
- Large Drives and old data — dozens of gigabytes of old files slow down the sync. A clean-up round in advance saves time, storage costs and hassle.
- Mobile devices — phones and tablets need to be set up again. Plan this in your communication, otherwise the notifications all come in on the first working day.
Do it yourself or outsource?
A migration of a handful of users without shared mailboxes or complex integrations is perfectly doable yourself with the right tools. Once it gets bigger — multiple departments, SharePoint, legacy systems or a merger where environments are combined — the experience of a party that does it more often quickly outweighs the cost.
As a rule of thumb (indicative): for a small team a migration is often done within one to two weeks, larger environments you plan in phases over several weeks. The project price depends on the number of users, the amount of data and the complexity — always ask for a fixed price based on a short inventory, so you don't face any surprises.
RiverFlows deliberately does both ecosystems — Microsoft 365 and Google Workspace — and both builds and manages. That is why we advise honestly which direction is smartest for you, instead of talking up the platform that happens to suit us best. After the switch we can take over your outsourced IT management, so your new environment stays in good shape.
In short
- A successful migration is a project with a playbook, not a copy-paste job — take stock, pilot, synchronise, and only then switch over.
- You prevent downtime by synchronising mail and files in advance and planning the DNS cutover outside working hours, with a fallback option as a safety net.
- Most problems are in the edge cases: shared mailboxes, permissions, hidden forwarding rules and large, cluttered Drives.
- Choose deliberately between Microsoft 365 and Google Workspace in advance, so you don't have to migrate the other way again within a year.
Read more
- Google Workspace vs Microsoft 365: which do you choose?
- Microsoft 365 migration without downtime
- Outsourced IT management
- What does IT management cost?
Frequently asked questions
How long does a migration to Microsoft 365 take?
For a small team a migration is often done within one to two weeks. Larger or more complex environments — with multiple departments, SharePoint or legacy systems, for example — are planned in phases over several weeks. The duration depends mostly on the amount of data and the number of users. By running a pilot first, the main switch-over afterwards becomes predictable.
Will my team experience downtime during the switch?
No, not if you plan it properly. Mail and files are synchronised in advance while the old system keeps running, so everything is already in place before you switch over. The final DNS cutover happens outside working hours, in the evening or at the weekend. Your people can simply keep working until that moment and barely notice the actual cutover.
What happens to shared mailboxes such as info@ and sales@?
We bring them along, but they need extra attention because shared and functional mailboxes work differently in Microsoft 365 than in Google Workspace. We make sure the right people can access them again after the switch, including the associated permissions and forwarding rules. These edge cases are exactly where sloppy migrations run aground, so we test them as early as the pilot phase.
Can I go back if something goes wrong during the migration?
Yes. Until the migration is definitively confirmed, the old environment stays available as a fallback. A migration should be reversible up to the moment you are certain everything is correct. That is why we schedule the switch-over at a quiet time, so there is room to adjust before everyone gets back to work. It is deliberately not an irreversible big bang.
What does a migration to Microsoft 365 cost?
That depends on the number of users, the amount of data and the complexity, such as shared mailboxes, SharePoint or old systems. A fixed project price based on a short inventory gives you clarity up front, so you don't face any surprises. All the figures you see online are indicative; always ask for a quote based on your situation.
Do you also migrate from Microsoft 365 to Google Workspace?
Yes, we migrate in both directions. Whether you want to move from Google Workspace to Microsoft 365 or the other way around, we move mail, calendars, contacts and files while preserving structure. Because we do both platforms, we also advise honestly which direction is the smartest for your organisation instead of blindly picking a camp.
Prefer insights like these in your inbox?
Leave your email address and we'll add you to the list and email you as soon as the next edition on IT, automation and dashboards comes out. You can unsubscribe at any time with a single email.