GUIDE · Updated April 15, 2026 · 9 min read

How to choose a cloud migration tool in 2026

Picking the wrong migration tool costs a weekend. Picking the right one makes a 10 TB tenant-to-tenant move look uneventful. This guide is the decision framework we wish every IT team had before they kicked off a migration project — the criteria that actually matter, the ones that sound important but do not, and the specific questions that separate a polished demo from a real capability.

The criteria that actually matter

1. Platform coverage against your real inventory

Start by writing down every source system you need to move from and every destination you need to move to. Include the long-tail systems: legacy InfoPath forms, archived Teams channels, SharePoint on-prem farms, old Google Shared Drives, SFTP servers nobody owns anymore. A tool that covers 90% of your estate still leaves a manual slog for the last 10%.

Red flag: a vendor that claims “any-to-any” without publishing a platform matrix. The ones who have really shipped the connectors will show you the list.

2. Metadata fidelity — especially on SharePoint

This is the question most evaluation checklists miss. When a tool moves a SharePoint list item from source to destination, does the item show up with its original Author / Editor / Created / Modified, or does the destination show today’s date and the migration service account?

The honest answer for most tools is “today’s date” unless the tool uses Microsoft’s native SharePoint Migration API (SPMT) under the hood. Graph’s /items POST silently rewrites those fields. If your compliance or audit posture depends on original authorship, ask the vendor whether they use SPMT or Graph, and for SharePoint specifically, whether they can preserve the full version stack or only the latest version.

3. Auth model — service account vs. user OAuth

Migration tools authenticate in one of two ways:

• Service account / app-only. Good for unattended automation, nightly scheduled runs, and large bulk moves. Downside: SharePoint’s migration API (the one that preserves original metadata) rejects app-only tokens acquired with a client secret, so metadata gets rewritten.
• User OAuth / delegated. Preserves original metadata on SharePoint migrations. Downside: requires a human to sign in every ~90 days, and migrations are attributed to the signed-in admin. Throttling is heavier than app-only.

A mature tool supports both and lets you pick per job. Ask for a demo that shows switching between them.

4. Pricing shape

Three common shapes, each with different failure modes:

• Per-GB. You pay for what you move. Aligns vendor incentive with your success — a failed upload is revenue they did not earn. Best for variable or one-off workloads.
• Per-user. You pay per mailbox or per seat. Predictable budgeting, painful if a user has 200 GB of OneDrive.
• Annual subscription / license. Flat fee, unlimited use during the term. Best for teams running back-to-back projects.

Red flag: any pricing that punishes retries. If the vendor bills for every failed attempt, they have no incentive to improve reliability.

5. Speed, honestly measured

“Fast” is the most abused word in migration marketing. Ask for a specific number (GB/hour) on a specific workload (SharePoint sites, OneDrive, mail), and ask whether it includes the time to scan, upload, and verify — or just the transfer itself. Also ask about the API ceiling: Microsoft Graph caps at roughly 600 requests/minute per tenant per app. Any tool claiming 1 TB/hour on SharePoint is either running multiple app registrations or marketing-maths.

What actually moves the needle: parallel chunk uploads, Graph $batch for metadata operations, HTTP connection keep-alive, and honest 429 back-off. Ask for the tool’s concurrency strategy; if the sales rep cannot answer, the engineering team probably has not thought about it.

6. Reliability signals

What to actually verify in a trial:

• Does the tool verify every uploaded file landed on the destination (size or checksum), or does it mark “success” on HTTP 200 alone? Silent partial writes are the worst-case failure mode.
• Does it resume cleanly when a network blip interrupts the job, or does it restart from zero?
• What happens to in-progress files when the backend crashes? Do they retry automatically, or do they sit wedged until you manually intervene?
• Does the progress counter ever show 100% before it’s actually done? That is a trust killer.

You can find all four of these by running a medium-size pilot (~50 GB, a few hundred files) and deliberately stressing it — pull the network cable, force-kill the browser tab, watch what the tool does.

7. Reporting you can hand to an auditor

Every migration produces an exception list — files that were skipped, items that failed a schema check, permissions that did not resolve. Can the tool export that list as CSV? JSON? PDF? Does the report include which field failed, or just “upload failed”? For any migration that touches a regulated industry, the report is the migration. Without it, you cannot prove the move was complete.

8. Cross-tenant capability for M365

Moving from one Microsoft 365 tenant to another is fundamentally different from same-tenant. UPNs change, guest invites need to be pre-provisioned, permission replay has to rewrite every principal reference. Ask: does the tool accept a user-mapping CSV? Does it surface unmapped principals before the replay runs, or after the damage is done? Can it invite unmapped users as B2B guests in the destination tenant?

The criteria that sound important but don’t matter (for most teams)

Raw platform count

“50+ platforms supported” means nothing if the 3 you care about are supported poorly. Ten platforms supported well beats fifty supported superficially. Check the platforms you actually need, not the marketing count.

“AI-powered” anything

Migration is a mechanical problem. Schema sequencing, byte-range chunking, retry logic, metadata mapping — none of this benefits from an LLM. If a vendor is leading with “AI-powered migration” in 2026, they are selling a feature for the investor deck, not the operator.

Desktop app vs. SaaS

This matters in one direction: if you work from a Mac or Linux and the tool is Windows-desktop-only, you have a problem. Otherwise, a good SaaS and a good desktop tool are roughly equivalent — the SaaS is just easier to collaborate on and survives your workstation rebooting.

Evaluation checklist — run this on every tool

1. Write down every source and destination platform you need. Verify each one in the tool’s published connector list.
2. Run a 50 GB pilot on real production data (not a test tenant with dummy files).
3. Inspect the destination: are the Author / Editor / Modified columns correct, or are they rewritten to today’s date with the service account as author?
4. Pull the network cable mid-run. Watch what happens. Does the tool resume cleanly, or does it fail the whole job?
5. Kill the worker / browser. Does the tool re-queue the in-flight files on next run, or do they hang forever?
6. Export the post-run report. Can you hand it to an auditor?
7. Migrate cross-tenant. Upload a user-mapping CSV with one bad UPN. Does the tool flag it before the replay, or only after?
8. Check the pricing shape against your actual workload. Model the three biggest migrations you have coming up.

What MigrationFox does

We built MigrationFox because the two-weekend SharePoint migration should not be a rite of passage. Every item in the decision framework above is something we have engineered around or written about:

• Full SharePoint site migration with schema-first phase ordering and True History Mode that preserves original Author / Editor / Created / Modified natively.
• Both auth models in one wizard — service account for automation, OAuth sign-in for metadata fidelity.
• Per-GB pricing — you pay for what you move, not for seats you do not have.
• Read-after-write verification on every file. A size or checksum mismatch retries; an empty upload response throws. We refuse to mark a file complete without evidence.
• Automatic retry of stranded in-progress records on worker restart. Crashes heal themselves.
• Cross-tenant permission replay with CSV mapping and unmapped-principal exception list before anything is written.
• Auto-split for large jobs — parallel workers, real-time file-level progress, exception reports as JSON / HTML / CSV.
• Eleven platform connectors (SharePoint, OneDrive, Google Drive, Gmail, Exchange, Dropbox, Box, Azure Blob, S3, SMB / Windows file shares, SFTP) plus chat migration (Teams / Slack).

A good migration tool makes the move invisible to the end user. They open the destination on Monday and everything is where they left it, with their name on it and the dates they remember. That is the bar, and it is the only bar that matters.

Start with a pilot

The only reliable way to evaluate a migration tool is to run your actual data through it. MigrationFox includes a free workspace with enough capacity to pilot a SharePoint site or a OneDrive before you commit. Use the checklist above. Trust your own eyes on the destination.