Microsoft 365

Cutover or staged migration: which approach fits?

The deciding factors are data volume, user count and how much downtime the business can absorb. A cutover migration moves everyone at a single point, usually over a weekend: mail flow switches once, there is one set of client reconfigurations, and by Monday everybody is on the new platform.

It is simpler, cheaper and lower in coordination overhead, and it works well for smaller estates with manageable mailbox sizes. Its weakness is that it is a single event with no partial rollback: if something is wrong on Monday morning, it is wrong for everyone at once.

A staged or coexistence migration moves users in batches while both environments run in parallel, with mail routing and, ideally, free/busy calendar lookup working across the boundary. It costs more in complexity and takes longer, but it lets you pilot with a tolerant group, catch problems while they affect ten people rather than three hundred, and pause.

Choose it when mailboxes are large, when the migration window is constrained by throttling or bandwidth, when there are shared mailboxes and delegate relationships that must not break mid-move, or when the organisation genuinely cannot be offline.

What does Microsoft 365 governance actually mean?

Governance is the set of decisions about who can create what, who can share what with whom, and what happens to content over time. In a Microsoft 365 tenant it has three practical strands. Sharing: whether external sharing is permitted at all, whether links default to 'anyone with the link' or to named people, whether unauthenticated links expire, and whether guests can be invited by any user.

The reason this matters more now than it did five years ago is that search and AI collapse the practical difference between 'technically accessible' and 'findable'. Content buried three levels deep in a forgotten site used to be effectively invisible; a semantic search surfaces it instantly.

If a document was overshared in 2021 and nobody noticed because nobody knew the path, the exposure existed all along; Copilot simply makes it visible. Governance work is therefore not a tidy-up exercise, it is the prerequisite for turning anything on that reads across your data.

Business Premium, E3 or E5: how do you decide?

The first hard boundary is headcount: Microsoft 365 Business Premium is capped at 300 seats, so above that the choice is between E3 and E5 regardless of anything else.

Below 300, Business Premium is unusually good value because it bundles the Office applications with a security stack most organisations otherwise buy separately: Intune for device management, Entra ID P1 for Conditional Access, Defender for Office 365 for link and attachment protection, and Defender for Business for endpoint detection and response. Bought as add-ons, that collection costs considerably more than the difference in seat price.

The E3 versus E5 decision is mostly about whether you would otherwise buy the security and compliance components separately, and whether you have anyone to operate them. E5 adds Entra ID P2, which brings risk-based Conditional Access, Privileged Identity Management for just-in-time administrative access, and access reviews; it adds the higher Defender tiers and the fuller Purview capabilities.

The honest test is whether those capabilities will be configured and monitored. E5 licences generating alerts nobody reviews are shelfware with a compliance story attached, and a mixed estate (E5 for administrators, finance and executives, E3 for everyone else) is often the right shape.

Intune or Group Policy: do you need both?

If your devices are domain-joined and never leave the network, Group Policy still works. If they are Entra-joined laptops that connect from home and only see a domain controller when someone happens to be in the office, Group Policy stops applying reliably and you are managing a fleet on trust.

Migration is rarely a clean switch. Intune's settings catalogue and ADMX-backed policies cover the large majority of what most GPO estates actually use, and Group Policy analytics will import your existing GPOs and report what has a direct equivalent (a useful reality check, because most estates find a meaningful share of their policies are obsolete rather than untranslatable).

What genuinely does not carry over are logon scripts that depend on domain resources, drive mappings to on-premises file servers, and policies for legacy applications that assume a domain context.

How should Teams, SharePoint and OneDrive fit together?

Each has one job, and most tenants get into trouble by blurring them. OneDrive is for work in progress that belongs to one person. SharePoint is the system of record for content the organisation owns, structured into sites that reflect how the business is organised.

Teams is the collaboration surface over the top: every team you create silently provisions a Microsoft 365 group and a SharePoint site behind it, and the Files tab in a channel is a folder in that site. Understanding that relationship prevents the most common mistake, which is treating Teams and SharePoint as competing places to put things when they are the same place with two front doors.

The structural decisions that matter are how many sites you create and how you handle permissions. Flat and broad beats deep and nested: a smaller number of purposeful sites with clear ownership is easier to secure and easier to search than a hierarchy that mirrors an org chart from three restructures ago.

Permissions should be granted through groups rather than to individuals, and unique permissions on individual folders should be rare, because they are invisible to anyone browsing and become impossible to audit at scale.

What actually breaks in a rushed migration?

The failures are consistent, and almost all of them come from discovery that was skipped rather than execution that went wrong. Shared mailboxes and delegate access break when permissions are not mapped before the move, so a PA who has managed a director's calendar for years suddenly cannot see it.

Distribution lists get missed. Public folders, which nobody remembers exist, turn out to hold a decade of shared correspondence. Applications, scanners, copiers and line-of-business systems that relayed mail through the old server stop sending, and nobody notices until an invoice run silently fails.

The second category is identity and mail hygiene. If SPF, DKIM and DMARC are not corrected as part of the cutover, your legitimate mail starts landing in junk folders at exactly the moment the business is most sensitive to disruption.

And if governance is deferred until after go-live, the tenant is built on defaults that permit broad external sharing and unrestricted site creation, which is far harder to unwind later than to set correctly at the start. The pattern is that migration problems are discovery problems.

Does Microsoft back up your Microsoft 365 data?

Not in the way most people assume. Microsoft's shared responsibility model makes them accountable for the availability and resilience of the service, and you accountable for your data within it.

Recycle bins have finite windows, and once they lapse the content is gone.

The related question is what happens to a leaver's content, because that is where organisations lose data quietly. When a user account is deleted, their OneDrive is retained for a limited default period before permanent deletion, and their mailbox goes the same way unless it was placed on hold before the licence was removed.

Both of those are configurable, but only in advance. The decision about how much history you need, for how long, and whether platform retention alone is sufficient is a business and regulatory question that should be answered deliberately rather than inherited from a default.