USE CASES

Pick the scenario that matches your project

MigrationFox gets used for a small number of distinct problems. Each one has a playbook — the tools to use, the order to use them in, and the checkpoints before the real cutover. Start with the scenario closest to yours.

Tenant → Tenant Workspace → M365 Mega-site restructuring Copilot readiness File server → cloud Platform consolidation
M&A · divestiture · rebrand

Microsoft 365 tenant-to-tenant migration

A merger, an acquisition, or a rename — content, mailboxes, Teams, and SharePoint sites move from one M365 tenant to another. Principals do not exist on the destination until you map them. The weekend window is short, the stakeholders are watching, and the fallback is never “try again next Saturday”.

The playbook

  1. Run an M365 Complete assessment on both tenants to understand the baseline. Identify oversharing, orphaned teams, and Must-Do findings before any data moves.
  2. Build the user mapping. CSV upload of source UPN to destination UPN. Principals without a destination match get flagged so you can decide — map to an archive account, skip, or block.
  3. Run Migration Rehearsal against a representative source site. Review the 10-category issue report; resolve schemaMismatch, permissionRisk, and pathTooLong before the real run.
  4. Enable Client Live View for the stakeholder sponsoring the cutover. They watch a branded status page instead of calling you.
  5. Run the cutover. Files, Teams, SharePoint, and mailboxes in parallel. Auto-split partitioning so large sites do not block small ones.
  6. Keep the seven-day rollback window open until you and the stakeholder sign off. If anything lands wrong, preview the revert before committing.

Tools you will use

ASSESSM365 Complete assessment — baseline the source and destination tenants
MAPUser mapping CSV upload — source UPN to destination UPN
REHEARSEMigration Rehearsal — dry-run with issue report and runtime prediction
MIGRATEFiles, Teams, SharePoint, mailboxes in parallel
MONITORClient Live View — branded share link for the stakeholder
ROLLBACKSeven-day reversible window on every completed migration
Start tenant-to-tenant → Cross-tenant permission deep dive
Platform migration · end-state Microsoft 365

Google Workspace to Microsoft 365

The organisation is standardising on Microsoft 365. Drive files, Shared Drives, Gmail mailboxes, and team chat need to land in SharePoint / OneDrive / Exchange Online / Teams with permissions preserved. Workspace-specific items (Google Docs, Sheets, Slides) need an auto-export policy before they move.

The playbook

  1. Scan every Workspace user. Build the inventory, see the file count and size distribution, identify oversized content (Video, .mp4, large CAD files) that may need special handling.
  2. Decide the auto-export policy. Google Docs → .docx, Sheets → .xlsx, Slides → .pptx. The migration engine exports on the fly.
  3. Map users. Workspace email → M365 UPN. External shares on Workspace files get a destination decision (preserve, strip, or substitute).
  4. Migrate drive content. My Drive goes to OneDrive. Shared Drives go to SharePoint site collections (one per Shared Drive by default).
  5. Migrate Gmail. Folder structure preserved, labels mapped to Exchange folders, attachments inline.
  6. Post-migration: run a Copilot Readiness assessment on the destination to catch oversharing that came in with the move.

Tools you will use

RELIABILITYReliability playbook — why Google Drive migrations fail at 99% and how we fix it
ASSESSCopilot Readiness assessment — post-migration oversharing check
Start Workspace migration → Full walkthrough
Information architecture fix

SharePoint mega-site restructuring

A single SharePoint site collection has grown to 240,000 files across eight departments. Permissions are set at the file level, inheritance is broken in 4,000 places, and every Copilot search returns documents from three other departments. The fix is to break the mega-site into properly scoped site collections — one per business unit — with permissions inherited cleanly from the site-collection root.

The playbook

  1. Run the Restructuring Wizard. It analyses the site and proposes a plan: which libraries become which new site collections, where the boundary between departments lives, and which permissions can be hoisted from file-level to site-level.
  2. Approve the plan. Review the proposed site map. Adjust anything that does not match the org’s actual structure.
  3. Auto-provision the destination sites. Each new site collection gets created with the right template, permissions, and site columns.
  4. Run the library-level migrations. MigrationFox queues one migration job per library, parallelises across sites, and keeps permissions clean at the site-collection level.
  5. Run a SharePoint & OneDrive Oversharing assessment against the old mega-site and the new collection to confirm the fix took.
  6. Decommission the mega-site once the rollback window closes and the oversharing score has improved.

Tools you will use

PLANRestructuring Wizard — proposes the new site layout from the current health scan
ASSESSSharePoint & OneDrive Oversharing — before and after
MIGRATESharePoint → SharePoint, library-level, parallel jobs
ROLLBACKSeven-day window in case a department boundary was drawn wrong
Start restructuring → Restructuring docs
Pre-rollout posture · ongoing governance

Copilot readiness for enterprise

The organisation is rolling out Microsoft 365 Copilot. Before the first licence is assigned, somebody needs to verify the tenant is not about to surface salary spreadsheets, M&A documents, or HR disciplinary records through a chat interface. Copilot respects existing SharePoint / OneDrive permissions — which is exactly the problem, because existing permissions are usually broken in ways nobody has audited.

The playbook

  1. Run the free Copilot Readiness snapshot. Composite score, 4-state verdict, module scorecard, one sample finding per module. Decide whether to go deeper.
  2. Buy the full assessment. Read-only Graph scan, 14 read-only scopes, 3–5 minutes on a typical tenant. Produces PDF, JSON, CSV exports.
  3. Review Must-Do-Before-Copilot findings. These are blockers — address them before the first licence.
  4. Fix what you can in-product. Restructure mega-sites, clean up OneDrive, remove Anyone-links on sensitive libraries.
  5. Enable continuous monitoring. Monthly re-run, trend chart, email alert on any new Must-Do finding. Governance becomes ongoing, not one-shot.
  6. Deliver the white-label PDF to the CIO / CISO / steering committee. The composite score is the headline; the module breakdown is the detail.

Tools you will use

MONITORContinuous Monitoring — monthly re-run with diffs and email alerts
DELIVERWhite-label PDF with client branding (bundle tier)
Run free snapshot → Deep dive
Data-centre exit · office closure

Windows file server to cloud

An aging on-prem Windows file server is being retired. Half a terabyte of files, NTFS ACLs to preserve, long paths everywhere, and a set of users who will keep editing during the move. The destination is usually SharePoint Online or OneDrive, occasionally AWS S3 or Azure Blob for cold storage.

The playbook

  1. Install the Windows agent on a server with SMB access to the file share. No inbound firewall ports; the agent polls for jobs.
  2. Run discovery. Inventory file count, size, and depth. Long-path and invalid-character reports highlight items that will need sanitising.
  3. Map NTFS ACLs. Domain principals → Azure AD users / groups. The mapping is interactive for anything ambiguous.
  4. Run Migration Rehearsal. Catches the oversized-file / path-too-long issues in advance.
  5. Migrate. Parallel file streams from the agent to the cloud destination. Junk-file auto-skip trims the inventory before bytes move.
  6. Run delta sync over the cutover weekend to catch anything users changed during the initial pass.

Tools you will use

CLEANJunk-file auto-skip — filters .DS_Store, Thumbs.db, and the rest
DELTAIncremental re-runs pick up only the files that changed since last pass
Start file server migration → SMB playbook
One vendor, one login, one invoice

Platform consolidation

The organisation runs Dropbox, Box, and a small SharePoint deployment. Leadership wants to consolidate on Microsoft 365. That is three sources, one destination, with three different permission models and three different sharing conventions to reconcile.

The playbook

  1. Inventory each source. Dropbox team folders, Box enterprise content, SharePoint libraries. Build a combined content map.
  2. Design the destination layout. Usually one SharePoint hub per business unit, with OneDrive for individual content.
  3. Reconcile sharing conventions. Dropbox shared links, Box collaborations, SharePoint Anyone links. Decide a destination policy per class.
  4. Run three parallel rehearsals. One per source. Each produces a verdict and an issue list.
  5. Migrate in a staggered schedule. Department by department, not all at once.
  6. Audit the destination with a SharePoint & OneDrive Oversharing assessment to catch imported-from-source problems.

Tools you will use

SOURCESDropbox · Box · SharePoint
DESTINATIONSharePoint Online · OneDrive for Business
Start consolidation →

Not sure which scenario is yours?

Start with the free tier. Every connector, the discovery scan, and the free governance snapshot are included. Pick your path once you see what is actually in the source.