Migrating to Microsoft 365 is one of the most common IT projects a London business will take on, and the biggest fear is almost always the same: will email stop working, will staff lose files, and will we grind to a halt for a day? The good news is that with proper planning, a phased approach and the right cutover method, a Microsoft 365 migration can be run with little or no perceptible downtime. This guide explains, in plain terms, how experienced teams sequence a migration so that mailboxes, documents and collaboration tools keep working throughout — and where the real risks lie.
What 'no downtime' actually means in practice
It helps to be honest about terminology. A migration with genuinely zero interruption at every layer is rare; what most businesses want and can realistically achieve is no loss of access to email and files during working hours, and no data loss. Staff should be able to keep sending and receiving mail throughout the transition, with only a brief, scheduled reconfiguration on their devices.
The way you achieve this is through overlap. Rather than switching everything off on Friday and hoping it works on Monday, a well-run project copies data into Microsoft 365 while the old system stays live, verifies it, and only redirects mail flow once the new environment is proven. The 'cutover' — the moment DNS points at Microsoft 365 — is then a small, controlled event rather than a leap of faith.
For a small London office of, say, 10 to 40 users, this typically means users notice nothing more than a prompt to sign in again and perhaps a short pause in new mail arriving during the final DNS switch, which is usually scheduled for the evening.
Step one: audit what you actually have
Every clean migration starts with an inventory. You cannot move what you have not measured. This means documenting your current email platform (on-premises Exchange, Google Workspace, a POP/IMAP host, or an older hosted Exchange), the number and size of mailboxes, shared mailboxes, distribution lists and any public folders.
Beyond email, you need a picture of file storage: local file servers, network shares, existing OneDrive or Dropbox usage, and how much data lives where. Large mailboxes and multi-terabyte file shares change the timeline significantly because copying that volume takes time and bandwidth.
This is also the point to record the awkward details that derail migrations: shared calendars, application accounts that send email (finance systems, scanners, CRMs), mobile devices, and any line-of-business software tied to the current platform. A thorough audit is the difference between a predictable Microsoft 365 migration and a series of unwelcome surprises on cutover night.
Step two: choose the right migration method
The method you choose depends on your source system and how much data you are moving. Picking the wrong one is a common cause of extended, avoidable downtime.
Each approach has trade-offs around speed, coexistence and complexity, so the decision should be based on your audit rather than habit.
- Cutover migration — moves all mailboxes in one go; suits smaller Exchange environments but offers the least overlap.
- Hybrid migration — keeps on-premises Exchange and Microsoft 365 running together, ideal for larger or phased moves where coexistence matters.
- IMAP migration — used for Google Workspace or generic hosting; reliable for mail but does not carry calendars or contacts, which need a separate step.
- Third-party tools — specialist migration platforms that handle Google Workspace, tenant-to-tenant moves and large file shares with detailed reporting.
Step three: prepare the Microsoft 365 tenant first
Before any data moves, the destination needs to be ready. This includes creating the tenant, assigning the correct licences, and configuring users, groups and shared mailboxes to mirror the source. Getting this right in advance means the cutover is about flipping a switch, not building an environment under time pressure.
Security should be baked in from the start, not bolted on later. Multi-factor authentication, conditional access policies and sensible default sharing settings belong in the build phase. Pairing the migration with proper identity protection avoids the trap of migrating first and securing later, which leaves a window of exposure.
Domain verification is a quiet but important task here. You prove ownership of your domain to Microsoft early, so that on cutover night the only remaining change is the mail routing (MX) record — a change you have already planned and can execute quickly.
Step four: pre-stage the data while the old system runs
This is the heart of a low-downtime migration. Using your chosen tool, you begin copying mailbox contents and files into Microsoft 365 days before the cutover, while everyone continues working normally on the existing platform. Because the source stays live, there is no interruption during this bulk copy.
For file data, tools such as the SharePoint Migration Tool or Microsoft's migration service move network shares into SharePoint and OneDrive, preserving folder structures and, where configured, permissions. This is also the natural moment to review how your teams collaborate and whether a straight lift-and-shift or a redesigned structure serves you better — something worth planning with SharePoint consultancy if your current shares are chaotic.
A day or two before cutover, a final incremental sync catches anything that changed since the bulk copy. This delta pass is quick because most of the data is already in place, which keeps the final switch short.
Step five: the cutover — timing and communication
The cutover is when new mail starts flowing to Microsoft 365. It is triggered by updating your MX and autodiscover DNS records, ideally with a low time-to-live set in advance so the change propagates in minutes rather than hours. Most London businesses schedule this for a weekday evening or over a weekend so the last few messages route to the new system before staff arrive.
Communication matters as much as technology. Users should be told in advance what to expect: a prompt to sign in with their existing address, possible re-entry of the Outlook profile, and reconfiguration of mobile mail apps. A short, clear one-page guide reduces the volume of first-morning support calls dramatically.
On the morning after cutover, having support on hand — whether your in-house team or a provider offering remote IT support — turns the inevitable small queries into quick fixes rather than a productivity dip. This 'hypercare' period usually lasts a few days.
Step six: verify, secure and decommission
Once mail is flowing and files are accessible, verification confirms the migration succeeded: test mail flow in both directions, check calendars and shared mailboxes, confirm mobile devices connect, and validate that application accounts (scanners, alerts, finance software) can still send. Only when these pass should you consider the project complete.
Do not switch off the old system immediately. Keeping the source platform running in read-only mode for a couple of weeks provides a fallback and lets you retrieve anything that was missed. Decommissioning too early is a classic mistake that turns a minor gap into a crisis.
Finally, tighten the environment. Configure email authentication such as SPF, DKIM and DMARC to protect your domain from spoofing — a step often overlooked at go-live. Our guide to managed DMARC and broader email security covers why this matters for deliverability and brand protection after a move.
Common pitfalls that cause avoidable downtime
Most migration downtime is self-inflicted and predictable. The recurring culprits are underestimating data volume against available bandwidth, forgetting application and device accounts that send email, and leaving DNS time-to-live values high so the cutover drags on for hours.
Bandwidth deserves particular attention for London offices moving large file shares. If your connection is a contended broadband line, a multi-terabyte upload can take days and compete with day-to-day work. Businesses on a leased line have a far easier time, and it is worth reviewing connectivity before a big move rather than discovering the bottleneck mid-migration.
The other frequent issue is skipping the pilot. Migrating a small group of willing users first exposes the quirks — a stubborn add-in, an odd mailbox permission, a mobile device that won't reconfigure — while the stakes are low. A pilot is the cheapest insurance a migration can buy.
Should you run it yourself or use a partner?
A confident in-house team can absolutely run a small Microsoft 365 migration, especially a straightforward cutover for a handful of users. The tooling is mature and Microsoft's documentation is thorough. Where businesses get value from a partner is in the coexistence, security and edge-case handling that separate a smooth move from a stressful one.
A specialist brings a repeatable method, out-of-hours cutover capacity and experience of the specific failure modes that don't appear in documentation. If your team is already stretched, blending internal knowledge with external delivery through co-managed IT support keeps you in control while offloading the heavy lifting.
Whichever route you take, the principle is the same: overlap the old and new, pre-stage the data, make the cutover small, and keep a fallback. Do that and 'without downtime' stops being a hope and becomes the expected outcome. If you'd like a scoped plan for your office, our team is happy to talk it through — start with our contact page.
