Microsoft 365 Migration Best Practices
Most Microsoft 365 migrations don’t fail at the data copy. They fail at the operational seams: identity decisions made too late, security baselines added after the bulk move, file shares lifted-and-shifted with their permission sprawl intact, mail cutover scheduled the same week as a regulatory deadline. The technical work is mostly solved. The sequencing isn’t.
This is what we’ve learned running Microsoft 365 migrations for Oil & Gas, Financial Services, and Manufacturing clients across Edmonton, Calgary, Vancouver, and Toronto. It’s also what changed in 2025, including the May retirement of staged OutlookAnywhere onboarding that quietly broke a lot of older runbooks.
Microsoft 365 Business plans cap at 300 users. If you’ll grow past that during the migration, plan E3/E5 from day one rather than re-licensing mid-flight.
How to define “done”
A wave isn’t complete when data copy finishes. It’s complete when business validation, security validation, and support stabilisation are also done. That distinction is the cleanest tell between low-disruption migrations and rushed ones.
Before any tooling, define success at four levels: service continuity, data fidelity, security and compliance posture, and adoption.
| Objective | What to measure | Acceptance target | Why it matters |
|---|---|---|---|
| Service continuity | Major incident count during pilot, waves, cutover | No P1 outage attributable to the migration | Stops the project “succeeding” technically while breaking the business |
| Data fidelity | Migration of in-scope mailboxes, files, permissions, metadata, labels, holds | All in-scope content migrated, with documented exceptions and an approved remediation list | Forces clarity on what is and isn’t supposed to move |
| Security baseline | MFA, Conditional Access, emergency access, endpoint compliance, auditability | Required controls live before broad production cutover | Prevents a weaker posture post-migration than the one you started with |
| Compliance continuity | Retention, DLP, sensitivity labels, eDiscovery and holds, residency | Controls signed off by legal/compliance before regulated data waves | Keeps you out of accidental noncompliance on day one |
| Adoption and support | Pilot feedback, training completion, champion coverage, ticket trend | Support volume returns near steady state after hypercare | Measures whether the platform is actually usable at scale |
We use a version of this scorecard on every engagement. It tends to be the first thing procurement asks for and the last thing internal stakeholders want to write themselves. If you don’t have one, start here.
Pre-migration assessment
Assessment builds a single source of truth across users, groups, devices, applications, mailboxes, file shares, SharePoint sites, Teams, network paths, and compliance obligations. What you find here directly drives mapping, timing, performance expectations, permissions, and onboarding.
| Domain | Inventory | Tools / evidence | Why it matters |
|---|---|---|---|
| Users and identity | Users, groups, privileged admins, service accounts, UPN/domain issues, sync scope, source forests | AD and Entra inventory, sign-in reports, authentication design review | Determines sync scope, identity method, cutover order |
| Devices and management state | Join type, ConfigMgr/Intune status, Office version, BYOD, VPN/proxy dependency | Intune enrollment and co-management reports, Office readiness tooling | Drives endpoint migration path and Conditional Access readiness |
| Applications and integrations | Enterprise apps, service principals, ADFS-published apps, legacy auth use, SMTP/EWS/IMAP dependencies | Enterprise applications view, usage insights, app-discovery/CASB, ADFS migration discovery | Prevents sign-in failures and broken line-of-business workflows |
| Mailbox counts and sizes, archives, delegates, shared mailboxes, public folders, PSTs, relay devices, holds | Exchange reports, migration test batches, hold inventory | Determines method, concurrency, cutover window | |
| Files and collaboration | File shares, SharePoint farms, OneDrive use, Teams-connected sites, blocked file types, long paths, invalid characters, customisations | SPMT scan, Migration Manager scan, SharePoint assessment scans | Prevents mass exceptions and surprises with permissions/metadata |
| Network | Egress locations, latency, backhaul, VPN path, TLS inspection, proxy rules, endpoint change process | Microsoft 365 network connectivity test, endpoint web service, migration pilots | Affects user experience and migration throughput directly |
| Compliance and residency | Regulatory obligations, retention/legal hold scope, DLP needs, label taxonomy, audit log retention, residency constraints | Purview design workshop, legal/compliance review, residency architecture review | Ensures the target tenant can legally receive the data |
A central design decision: lift-and-shift, or selective modernisation. The right answer is usually neither. It’s lift-and-curate. Remove stale content, rationalise shared drives, separate personal from team-owned data, and simplify permissions before broad migration waves. Every fast migration we’ve audited followed a remove/migrate/rebuild model, applied before any tool ran.
A planning note for SharePoint specifically: the SharePoint Migration Assessment Tool reaches end of support on October 1, 2026. Microsoft directs customers to the SPMT scan capability for SharePoint Server sites. If your runbook assumes SMAT will stay around, update it now.
This assessment phase is where most of our SharePoint migration engagements start.
Identity, security, endpoint, compliance foundation
Identity gets decided before the first production wave. For most organisations, the lowest-risk target state is synchronised identity with cloud authentication. It reduces dependencies on on-premises authentication infrastructure while preserving a hybrid management path during transition.
| Identity option | Best fit | Strengths | Caveats |
|---|---|---|---|
| Password hash synchronisation (PHS) | Default for most organisations | Lowest deployment and maintenance effort, high cloud availability, works with Entra ID Protection and Entra Domain Services, supports seamless SSO | On-prem disabled/expired/locked-out states aren’t enforced instantly in the cloud. Deploy a staging Entra Connect server for resilience |
| Pass-through Authentication (PTA) with PHS backup | Organisations that must enforce on-prem account state and sign-in-hour policy at authentication time | Validates passwords against on-prem AD, supports policy enforcement at sign-in, PHS backup improves continuity | Requires agents with direct access to domain controllers. Microsoft recommends three agents. Failover to PHS isn’t automatic |
| Federation with AD FS | Only when Entra ID can’t natively satisfy a required scenario, or when third-party / on-prem MFA / specialised federation behaviour is mandatory | Maximum control and compatibility for specialised federation patterns | Highest infrastructure and continuity burden. Requires a farm and careful HA design. Still enable PHS backup |
The practical rule: choose PHS unless you have a concrete reason not to. Choose PTA when you must enforce on-prem policy at sign-in. Reserve federation for specific unsupported requirements. In all three cases, plan directory synchronisation, account cleanup, UPN normalisation, and role separation before production cutover.
We default to PHS on greenfield. We migrate clients off federation when their original “we needed it for X” is no longer required, which is more often than you’d expect.
Security baseline
Security controls go live before sensitive users or data land in Microsoft 365. The minimum baseline:
- MFA via Conditional Access, applied through staged groups with report-only mode first.
- Block legacy authentication after a report-only validation phase.
- At least two emergency access accounts with strong, separately stored credentials.
- Conditional Access plus Intune compliance or app protection to control device state.
Conditional Access requires Entra ID P1 licensing. Microsoft has separately enforced MFA across major admin portals, so your privileged accounts will need it whether you plan it or not.
For regulated clients (Financial Services under OSFI B-13, manufacturers under ISO 27001 commitments), we treat the security baseline as a procurement-blocker for production cutover. No baseline, no waves.
Endpoints
The cleanest endpoint strategy is usually: keep existing Configuration Manager investments through co-management where they earn their keep, but make net-new or refreshed devices cloud-native where application dependencies allow it. Use automatic enrollment and Windows Autopilot where appropriate. For BYOD without full enrollment, app protection policies are the right call. Don’t try to flip every device to cloud-native in one wave.
Compliance
Compliance architecture is foundation, not afterthought. Sensitivity labels classify and protect. Retention labels and policies govern lifecycle. DLP controls risky data movement. eDiscovery preserves and investigates content for legal or internal matters.
Teams complicates this because team data spans multiple storage locations: Teams files in SharePoint, chat files in OneDrive, retention and eDiscovery copies of messages in Exchange-related locations. Compliance scope has to reflect where the data actually lives. If you have data residency obligations, evaluate Multi-Geo or Advanced Data Residency before migration, not midstream.
This is the sort of work we package into a Microsoft 365 engagement, end-to-end with one delivery lead.
Mail migration
The state of mail migration is more nuanced than older playbooks suggest, because Microsoft retired Staged OutlookAnywhere onboarding on May 8, 2025. If your runbook still recommends staged Exchange onboarding as a mainstream approach, it’s out of date.
| Approach | Best fit | Coexistence | Strengths | Main caveats |
|---|---|---|---|---|
| Cutover Exchange | Small, simple Exchange orgs. Practical recommendation: ~150 mailboxes or fewer (support limit is 2,000) | Minimal | Fastest whole-org swing, simple architecture | Directory sync must be off. Limited coexistence. Cutover risk grows fast with size |
| Staged Exchange | Historical Exchange 2003/2007 scenarios | Partial / legacy | Older batch-based option | Retired May 8, 2025. Use hybrid remote onboarding or another method |
| Hybrid Exchange | Exchange 2010/2013/2016+ where gradual moves and rich coexistence matter | Richest Microsoft-native | Phased mailbox moves, full coexistence features. Standard choice over 150 mailboxes | Requires directory sync and the Hybrid Configuration Wizard. More setup |
| Minimal Hybrid / Express | Orgs that want a short-lived hybrid and quick mailbox moves over a couple of weeks or less | Limited but useful | Faster than full hybrid, preserves remote move capability | Still requires hybrid setup logic. Not a substitute for long-term coexistence |
| IMAP | Very old Exchange or non-Exchange systems with IMAP support | Low | Broad compatibility | Email only. No contacts, calendars, or tasks |
| Third-party / specialised | Cross-platform coexistence, complex tenant moves, mergers and divestitures, advanced Teams breadth | Depends on product | Broader workload coverage and operational flexibility | Added licensing and vendor dependency. Require POC effort |
The tradeoff is simple: cutover optimises speed and simplicity. Coexistence optimises business continuity and operational safety. If you have shared mailboxes, calendaring dependencies, phased device changes, complex relays, compliance constraints, or meaningful user support risk, coexistence is worth the extra setup cost.
Sizing and throttling
Mailbox sizing and throttling need explicit planning. A mailbox with many small items can migrate more slowly than one with fewer large items because item density matters more than total size. Microsoft’s default concurrent mailbox migration value is 20, raisable to 100 in supported scenarios, but the source system’s tolerance is what actually sets the ceiling. Hybrid moves can stall under resource-health-based throttling. Throttling exists to protect service reliability. Trying to disable it isn’t an option.
Mail-flow and DNS cutover
Plan and rehearse the sequence:
- Create the migration endpoint.
- Migrate and validate mailboxes.
- License users.
- Change the domain to route mail directly to Microsoft 365.
- Add the new MX. Remove or de-prioritise the old MX records.
During Exchange migration, keep the existing on-premises Autodiscover record in place until the migration is complete. Validate MX, SPF, Autodiscover, relay devices, and mailbox sign-in immediately after cutover.
Files, SharePoint, OneDrive, Teams
The architectural rule: stop thinking of “Teams data” or “file-share data” as one blob. Personal files, team files, SharePoint sites, Teams-connected content, mailbox-backed artifacts, version history, permissions, retention, and eDiscovery all behave differently. Design the target information architecture first, then map source content into the right destination:
- OneDrive for personal working files.
- SharePoint libraries for team content.
- Teams for collaboration experiences backed by SharePoint, Exchange, and Microsoft 365 Groups.
Permissions, metadata, version history, and exception handling get decided deliberately, not inherited accidentally from the old environment. This is the part of the project where lift-and-shift turns into multi-year sprawl. We lead with information architecture before migration, not after — see our deeper walkthrough on designing a SharePoint DMS with metadata and retention.
Tools
Use Microsoft-native tools by default unless the scenario needs more fidelity or restructuring than they provide. Migration Manager is Microsoft’s current admin migration hub for file shares and supported cloud sources (Google Drive, Box, Dropbox, Egnyte). SPMT remains the Microsoft-native tool for on-premises SharePoint and file shares. Mover is retired for admin-led migrations; those paths now live in Migration Manager.
SPMT supports a surprisingly wide modern SharePoint set: files, folders, list items, permissions, version history, managed metadata and taxonomy, navigation, many site features and web parts, pages, incremental reruns, and selection of Teams or channels as destinations. For straightforward on-prem SharePoint and file-share migrations, this can eliminate the need for third-party tools entirely.
Permissions
For file-share migrations, the most restrictive share or NTFS permission determines the final SharePoint permission. Read maps to Read. Write/modify typically maps to Contribute. Full control maps to Full control. But explicit deny permissions and advanced NTFS permissions are removed, and in SPMT, inherited permissions aren’t migrated. That’s why permission modelling and exception reporting belong in the assessment phase, not the validation phase.
Versions and metadata
Treat version history as a scope decision, not a default. SPMT supports managed metadata and term stores. Settings let you migrate the latest version, all versions, or a specified number. If audit, engineering records, or regulated processes need full history, capture that in scope and acceptance criteria. If they don’t, limiting versions improves throughput materially and reduces storage growth.
Teams
Plan a Teams migration as a set of interdependent workloads. A team uses a Microsoft 365 group, a SharePoint site and document library, and an Exchange Online shared mailbox/calendar. Files live in SharePoint. Chat files live in OneDrive. Retention and eDiscovery for messages relies on Exchange-backed locations.
Your Teams migration plan needs to specify what happens to: team structure, channel files, meeting data, calendars, OneNote notebooks, and compliance artifacts. The native Slack-to-Teams Migration Tool is solid for Slack sources. Tenant-to-tenant Teams fidelity is where most organisations end up evaluating third-party tools, because the native story for chat history and meeting artifacts is incomplete.
Performance planning
Performance planning should be empirical, not aspirational:
- Migration Manager and SPMT support files up to 250 GB.
- Migration speed scales with more agents until network limits are reached.
- A single Migration Manager agent processes up to 10 tasks concurrently.
- SharePoint Migration API planning estimates: light large-file content up to ~10 TB/day, medium Office-file mixes around 1 TB/day, metadata-heavy small-file content about 250 GB/day.
- Off-peak hours and Azure geography aligned with the tenant region both help.
- Microsoft can’t disable SharePoint throttling, even on request.
Network design
Network planning happens before the bulk data move, not after. The strongest baseline:
- Local internet egress from each major site.
- Split tunnelling for key Microsoft 365 traffic over VPN.
- DNS resolution close to egress.
- Avoidance of backhaul and TLS inspection for Microsoft 365 endpoints.
Validate the design with the Microsoft 365 network connectivity test and subscribe to the endpoint web service so URL/IP changes don’t quietly break your egress rules.
ExpressRoute is not recommended for Microsoft 365 in most circumstances and requires Microsoft authorisation for the rare cases where it’s justified. If a vendor pitches ExpressRoute as the default M365 path, push back.
Tooling
A sound tool strategy is Microsoft-native first, third-party where the requirements justify it. The clearest justifications for third-party are: tenant-to-tenant coexistence, large-scale mergers and divestitures, advanced Teams breadth, identity restructuring, complex reporting and remapping, or the operator experience of native tooling becoming the bottleneck rather than the service itself.
| Toolset | Best use case | Strengths | Cautions |
|---|---|---|---|
| Native Microsoft tools | On-prem SharePoint and file shares, standard Exchange migrations, file-share and cloud-source ingestion, Slack-to-Teams, selected cross-tenant scenarios | Included or first-party aligned. Respects service limits and admin workflows. Good fit for standard scenarios | Coverage is workload-specific. Complex Teams or tenant restructuring often needs supplemental tooling or process |
| ShareGate | Tenant-to-tenant, Google Workspace to M365, Exchange/SharePoint/Teams/OneDrive with a simpler operator experience | Broad M365 migration scope. Recent customer stories show fast Google-to-M365 execution | Still requires mapping design and testing. Verify feature coverage for niche workloads |
| AvePoint Fly | Large-scale content and identity migrations, mergers and consolidation, delta-sync and backup-aware execution | Strong discovery, staged cutover, identity and content breadth | Quote-based pricing. Evaluate complexity vs. native tooling before buying breadth you don’t need |
| Quest On Demand Migration | Tenant-to-tenant M365 consolidation with coexistence and identity breadth | Covers Exchange, OneDrive, SharePoint, Teams, AD/Entra. Coexistence and permissions/delegation are differentiators | Quote-based. Plan a POC to validate fidelity and operator workflow |
| BitTitan MigrationWiz | Mailbox, document, and tenant migrations where public per-user pricing and cloud delivery are attractive | Broad workload support, publicly visible pricing for some bundles | Not a sync tool. Items changed at source after migration aren’t updated at destination automatically |
We pick the tool after we understand the scope, not before. Tool selection up front is one of the more common ways migrations get more expensive than they need to be.
Licensing and indicative costs
Public list prices vary by geography, tax, channel, and Teams bundling. Indicative CAD annual-commitment list prices at time of writing:
| SKU | List price (CAD) | Best fit | Notes |
|---|---|---|---|
| Business Basic | 8.10/user/month | Small orgs needing core cloud services | Business family caps at 300 users |
| Business Standard | 17.00/user/month | Small orgs needing desktop apps + services | Same 300-user cap |
| Business Premium | 29.80/user/month | Small orgs wanting device management and stronger security | Often the most migration-friendly SMB landing zone, includes device and security value |
| Exchange Online Plan 1 | 5.40/user/month | Mail-only or staged landing mailbox scenarios | 50 GB primary mailbox + 50 GB archive |
| Microsoft 365 E3 | 50.80/user/month | Mainstream enterprise landing zone | Microsoft also lists a no-Teams packaging option separately |
| Microsoft 365 E5 | 77.30/user/month | Enterprise where advanced identity, security, compliance justify the premium | Strongest built-in feature set, materially higher recurring cost |
| Cross-Tenant User Data Migration add-on | One-time per user, quote required | Native cross-tenant mailbox and OneDrive migration | Required for native cross-tenant mailbox moves; also covers OneDrive |
Subscription-only orders of magnitude using those list prices: a 250-user org on Business Premium runs about CAD 89,400/year before tax. A 250-user mail-only landing zone on Exchange Online Plan 1 is about CAD 16,200/year. A 2,000-user enterprise on E3 is about CAD 1,219,200/year; on E5, about CAD 1,855,200/year. These are subscription costs only. They don’t include dual-running legacy systems, partner services, migration tooling, network changes, training, or hypercare.
FastTrack is worth evaluating early where Microsoft support benefits matter. Qualifying subscriptions get FastTrack — including data migration activities for supported file-share, Box, and Google Drive scenarios — at 150+ seats; the threshold was lowered from 500 in June 2025, so older runbooks that gate data-migration assistance at 500 licenses are out of date. Cross-tenant FastTrack is more restrictive and invitation-based.
Project structure
A simple structure that scales:
| Workstream | Owner | Core deliverables | Exit criteria |
|---|---|---|---|
| Program governance | PMO / executive sponsor | Scope, budget model, success metrics, risk log, decision forum | Scope and decision rights approved |
| Identity and access | Identity architect | Sync design, auth method, MFA/CA, break-glass, role model | Pilot sign-ins and admin access validated |
| Endpoint and apps | Endpoint lead | Co-management/Intune plan, app inventory, LOB testing, Office upgrade path | Pilot devices and critical apps validated |
| Mail and collaboration | Messaging/collab lead | Exchange path, file/SharePoint/Teams mapping, cutover plan, DNS plan | Wave runbooks rehearsed |
| Security and compliance | Security/compliance lead | Labels, DLP, retention, eDiscovery, residency decisions, audit coverage | Control owners sign off |
| Adoption and support | Change lead / service desk | Comms, training, champions, help content, hypercare workflows | Support team ready, pilot users trained |
We staff our migrations against a slimmer version of this. One delivery lead per engagement, senior consultants on each workstream, no handoffs between teams. Every project lead has shipped 5+ tenants.
Migration checklist
- Establish governance, business scope, success metrics, and decision rights before any technical work begins. Tie each wave to a business owner and an acceptance process, not just an admin task list.
- Build a full source inventory: users, groups, mailboxes, archives, devices, enterprise apps, file shares, SharePoint sites, Teams-connected content, compliance obligations.
- Classify source content into remove, migrate, or rebuild. Decide what should land in OneDrive vs. SharePoint/Teams.
- Baseline network readiness: Microsoft 365 network testing, local egress analysis, endpoint-list process, VPN split-tunnel design.
- Choose the identity pattern. Deploy Entra Connect and password hash sync backup, even if PTA or federation will be primary initially.
- Stand up the security baseline: MFA, Conditional Access in report-only where appropriate, emergency access accounts, legacy-auth blocking validation.
- Prepare endpoint management: co-management or Intune enrollment, app protection for BYOD, test rings for policies and Microsoft 365 Apps.
- Design the compliance landing zone: label taxonomy, retention model, DLP locations, eDiscovery role model, audit requirements, residency constraints.
- Remediate source exceptions: invalid file names, long paths, blocked file types, orphaned permissions, old Office versions, Basic-auth app dependencies, stale accounts.
- Pre-provision users, mailboxes, OneDrive, licenses, groups, and pilot devices before the main data move.
- Run a pilot covering representative users, large mailboxes, deep file paths, complex permissions, at least one critical application, and a realistic help-desk script. Use incremental migration where possible.
- Tune throughput and batching based on measured source capacity, throttling behaviour, and support capacity. Not on optimistic assumptions.
- Migrate production in waves. Keep coexistence where required. Run a final delta sync before each cutover moment.
- Execute mail-flow and DNS cutover deliberately. Validate MX, SPF, Autodiscover, relay devices, and mailbox sign-in behaviour immediately after cutover.
- Hold hypercare. Validate data and controls. Retire legacy infrastructure only after business acceptance, compliance sign-off, and rollback windows expire.
Change management
Communications and onboarding start early. The model that works is pilot-plus-champions: identify a local champion network, provide concise role-based training, publish self-serve learning content, and run structured communications before, during, and after each wave. Microsoft Learning Pathways is a useful free on-demand training framework.
A practical support model has three layers:
- Service desk playbook for common user issues.
- Migration command center for wave-day decisions and escalations.
- Specialist engineers for identity, mail flow, endpoint, and content exceptions.
The layered model matters most during cutover week and hypercare.
Sample timeline
Illustrative, not prescriptive. Actual duration depends on source complexity, coexistence needs, network readiness, and regulatory controls.
| Phase | Activity | Window | Duration |
|---|---|---|---|
| Foundation | Program mobilisation | May 04 – May 14 | 10d |
| Foundation | Discovery and assessment | May 11 – May 31 | 20d |
| Foundation | Identity and security baseline | May 12 – Jun 16 | 35d |
| Foundation | Network and endpoint remediation | May 12 – Jun 09 | 28d |
| Pilot | Pilot users, mail, files, devices | Jun 15 – Jun 30 | 15d |
| Pilot | Pilot review and go/no-go | Jun 30 – Jul 05 | 5d |
| Waves | Wave 1 | Jul 06 – Jul 21 | 15d |
| Waves | Wave 2 | Jul 27 – Aug 16 | 20d |
| Waves | Wave 3 | Aug 24 – Sep 13 | 20d |
| Cutover | Final delta sync, DNS cutover | Sep 21 – Sep 26 | 5d |
| Cutover | Hypercare | Sep 28 – Oct 08 | 10d |
| Optimise | Post-migration governance, tuning | Oct 05 – Oct 25 | 20d |
A real schedule for your organisation comes out of the discovery and assessment phase, not before it.
Validation and troubleshooting
Validation is structured by workload and by control, not by anecdote. At a minimum, validate:
- Identity sign-in patterns.
- Mailbox access and mail flow.
- File counts and spot-checked permissions.
- Teams and channel structure plus file access.
- Endpoint compliance and application behaviour.
- Purview controls: labels, retention, DLP, audit visibility.
Both automated checks and business-owner sampling matter. The automated checks tell you the data moved. The sampling tells you whether the people who actually use it can.
| Common issue | Likely cause | First checks |
|---|---|---|
| Mail migration is much slower than forecast | Source bottleneck, item density, migration-service throttling, too much concurrency | Mailbox density, source server load, default concurrency, queue/throttle data |
| SharePoint or OneDrive migration is slow | Network path, package design, off-peak usage, throttling | Local egress, package size guidance, off-hours scheduling, agent count |
| Permissions look wrong after file migration | Inherited permissions not migrated, explicit deny removed, restrictive mapping logic | Compare effective source permissions vs. mapped SharePoint roles. Review exceptions before blaming the tool |
| Teams content feels incomplete | Team data spans SharePoint, OneDrive, Exchange, and service structures | Confirm whether you migrated only files, only structure, or the full set of dependent workloads |
| Apps or devices stop sending mail | Legacy auth, Basic-auth dependency, SMTP/relay design not updated | Test client SMTP submission alternatives. Identify Basic-auth dependencies before cutover |
| Users unexpectedly blocked by security policy | Conditional Access rolled out too broadly or without exclusions/break-glass | Report-only results, excluded emergency accounts, device compliance state, pilot scope |
| Remote users get poor performance after rollout | Backhaul, proxy inspection, VPN design, bad egress location | WAN backhaul, split tunnel status, DNS location, TLS inspection bypasses |
Rollback
Rollback planning needs to be honest. In identity, the strongest “rollback” move is preventing tenant lockout in the first place: break-glass accounts plus password hash synchronisation as a continuity path. In Conditional Access, use report-only mode, staged groups, and explicit emergency exclusions. For endpoints, use rings and group-based assignments so policies can be withdrawn quickly.
For mail, a true full rollback is easiest before the authoritative DNS and mail-flow switch. After MX changes, rollback is usually a forward-fix with temporary coexistence or rerouting, not a clean reversion. That’s one of the strongest arguments for hybrid coexistence over hard cutover in medium and large environments. For files, frame rollback as preserved source plus incremental delta migration plus controlled source freeze plus backup/restore. Not “delete the destination and start over.”
Post-migration governance
Governance starts after the migration, not before it ends. The post-migration operating model needs:
- Label and retention lifecycle review.
- Periodic audit-log review.
- Ownership and access recertification.
- Endpoint update strategy.
- Microsoft 365 endpoint-change management (use the Microsoft web service for endpoint changes).
- Cleanup of stale collaboration spaces.
The collaboration-space cleanup matters more than people expect. Within a year, most tenants accumulate hundreds of orphaned Teams and abandoned SharePoint sites. Plan the lifecycle process up front rather than letting it pile up.
Where the guidance has limits
Three areas where the public Microsoft guidance is intentionally light, and where you’ll need to do more work:
Tenant-to-tenant Teams. Full-fidelity migration of chat history, meeting artifacts, and edge-case collaboration objects isn’t covered well by native tools. Slack-to-Teams is solid; tenant-to-tenant Teams is where most organisations evaluate third-party tools.
Pricing. Microsoft publishes list pricing for subscription SKUs, and some vendors publish partial pricing. Partner services, advanced tenant restructuring, and many enterprise migrations remain quote-based. Treat any commercial estimate as a range model plus POC, not a one-line procurement decision.
Jurisdictional compliance. The technical and operational framework above doesn’t substitute for legal and compliance review. Data residency, retention duration, encryption expectations, and hold procedures vary by geography and industry. Validate against your actual obligations before final cutover.
How we run these
We’ve shipped migrations across Edmonton, Calgary, Vancouver, and Toronto for Oil & Gas, Financial Services, and Manufacturing clients. Same delivery lead from discovery through hypercare. Senior consultants on every workstream. No handoffs between teams.
If you’re scoping a migration, the discovery conversation usually takes 45 minutes and ends with a written read of what’s actually possible in your environment, on your timeline. We don’t ship a deck. We ship the answer.