DEV Community: Tzunami

SharePoint Migration Tools: How to Choose One That Fits Your Content, Your Source, and Your Cloud

Tzunami — Fri, 09 Oct 2026 08:57:03 +0000

Most teams start shopping for SharePoint migration tools before they know what they are migrating. It feels like the logical first move, since the tool is the visible, purchasable part of the project. But the tool is only as good as the decisions behind it, and those decisions are usually unmade when the demos begin. The result is a familiar pattern: a pilot that goes smoothly on tidy folders, followed by a production run that stalls on long file paths, orphaned permissions, and metadata nobody mapped.

This article walks through the sequence that tends to work better. It starts with understanding the content, moves to the features that separate one tool from another, and ends with the practical realities of moving into Microsoft 365.

Start With a SharePoint Migration Assessment
A SharePoint migration assessment is the inventory-and-risk exercise that happens before any content moves. Done properly, it turns a vague sense of scale into a list of specific problems.
The inventory comes first: how many sites, libraries, and items exist, how big they are, and how old. Last-modified dates are the most useful single field. In most mature environments, a large portion of content has not been opened in years, and it is cheaper to archive or delete it than to migrate it. Teams that skip this step pay for the transfer, then pay again for storage and search noise in the new tenant.

Next comes the list of things SharePoint Online will not accept as-is. File paths are capped at 400 characters, and deeply nested folder structures from file shares often exceed that. Certain characters and trailing spaces in names are rejected, and some file types are blocked. Individual files above 250 GB will not upload. These issues are easy to fix in bulk before migration and tedious to fix one by one after a failed batch.

Customizations deserve their own review. Farm solutions, InfoPath forms, and SharePoint 2010 and 2013 workflows do not move to SharePoint Online. They need to be rebuilt, often in Power Apps or Power Automate, or retired. Microsoft has also ended support for older on-premises releases, with SharePoint 2013 out of support since April 2023 and the 2016 and 2019 versions following in 2026, which gives many organizations a firm deadline in place of a preference.

Finally, look at permissions. Broken inheritance, nested groups, and accounts belonging to people who left years ago are normal in long-running environments. Mapping them to Microsoft Entra ID is among the most error-prone parts of any project, and the assessment should produce a list of identities that need resolving before cutover.

What to Look For in a SharePoint Data Migration Tool
Once the assessment is done, requirements become concrete, and a SharePoint data migration tool can be judged against them rather than against a feature checklist.

Metadata and version fidelity
If your content carries custom properties, such as contract numbers, document classes, or review status, the tool needs a mapping interface flexible enough to transform values, handle multi-value fields, and populate managed metadata terms. It also needs a clear policy on versions. Migrating every version is slow and inflates storage. Migrating only the latest loses audit history. Good tools let you choose per project, or per library.

Permissions and identity handling
Check how the tool resolves users and groups from the source to Entra ID, what it does with unresolved accounts, and whether it can preserve unique permissions without flattening everything. Ask to see this working on a messy sample, not a demonstration set built to look clean.

Incremental runs and reporting
Large migrations are never a single event. Users keep working in the old system until cutover, so the tool must support delta passes that pick up only what changed. It should also produce item-level logs that let you reconcile source and destination. A migration you cannot verify is a migration you cannot sign off.

Link and reference handling
Documents often contain links to other documents, and sites contain links to pages that no longer exist after the move. Tools differ widely in whether they rewrite those references. Discovering the gap after go-live is one of the quicker ways to lose user trust.

Planning a SharePoint Migration Cloud Move
A SharePoint migration cloud project adds constraints that on-premises-to-on-premises moves never face. The most important is throttling. Microsoft 365 limits how fast data can be written to a tenant, and those limits tighten when many requests arrive at once. A tool that ignores them will see retries and failures. A tool that respects them will take longer than your bandwidth alone suggests, so schedule large batches outside business hours and build the timeline around real throughput, not theoretical speeds.

Most serious tools use Microsoft's Migration API, which stages content in Azure storage and imports it in bulk, and this is considerably faster than writing items one at a time through the standard APIs. Confirm that the tool you are evaluating uses it, and whether it needs a staging account you control or one it manages for you.

So, Which Is the Best SharePoint Migration Tool?
People searching for the best SharePoint migration tool want a single name, and a single name would be misleading. The right choice depends on the source system, the volume, the metadata complexity, the compliance requirements, and the skills available in-house. Microsoft's free tools are often the best choice for a straightforward file share move. A migration from a document management system with custom object types, deep version trees, and layered security usually justifies something more specialized.

When the source is an enterprise content platform rather than a file server, vendors that focus on SharePoint content migration, Tzunami's approach to SharePoint content migration being one example, tend to be built around the structural problems those moves create. The practical test is the same whichever product you consider: run it against a representative sample, including your worst folders and your oddest permissions, and see what it reports back.
Cost should be weighed against the effort it removes. A license that saves two weeks of manual remediation and re-runs may be cheaper than a free tool that needs a consultant to babysit it.

Making the Decision Stick
Tool selection works best when it comes late. Run the assessment, clean what you can, define how metadata, versions, and permissions will be handled, and write those rules down. Then test two or three candidates against the same pilot content and compare the logs, not the marketing.
What teams remember afterward is rarely the interface of the tool they used. It is whether the numbers matched on the day they switched off the old system, and whether the people who rely on the content found it where they expected. A tool chosen against that standard rarely disappoints.

Migrate File Server To SharePoint Online: Why The Old Approach Doesn't Work Anymore

Tzunami — Wed, 16 Sep 2026 07:15:22 +0000

A file server built in 2012 was never designed to live in the cloud. It has drive letters, mapped shares, and folder permissions inherited from people who left the company years ago. When enterprises try to migrate file server content into Microsoft 365 using basic copy paste logic, they inherit all of that mess along with the files. Tzunami has spent over two decades solving exactly this problem, and its approach starts from a simple premise: structure has to survive the move, not just the data.

Legacy file shares are still everywhere. IDC estimated back in 2021 that unstructured data, the kind sitting on file servers, was growing at roughly 25 percent annually inside large enterprises, far outpacing structured database growth. That volume doesn't disappear when a company adopts Microsoft 365. It just becomes a liability sitting on aging hardware that IT keeps patching instead of retiring.

The Real Cost Of Ignoring Legacy Systems
Every year a company delays a proper migration, the file server becomes riskier to touch. Permissions drift. Nobody remembers why a folder was locked down in 2015. When the eventual move happens, teams often reach for a generic file migration tool that simply copies bytes without preserving the logic behind them. That's how organizations end up with a SharePoint instance that looks like a dumping ground six months after going live.

Tzunami built its Deployer platform specifically to avoid that outcome. Rather than treating a file server as a flat collection of documents, it maps folder hierarchies, security groups, and metadata before migration begins, then replicates that structure inside SharePoint or Microsoft 365 rather than flattening it. That distinction, mapping before moving, is the single biggest predictor of whether a migration finishes clean or finishes in a support queue.

Here's a sentence worth keeping: a migration that ignores structure isn't a migration, it's a data dump with a deadline.

Open Text Content Server Migrations Need A Different Playbook
Migrating out of an Open Text Content Server environment is a different animal entirely from a standard file share move. OpenText systems typically carry decades of records management rules, retention schedules, and compound document relationships that a basic copy tool has no way of interpreting. Organizations running OpenText Content Server since the early 2000s often have millions of objects with custom metadata fields baked into legal and compliance workflows.

Tzunami has supported OpenText migrations for years precisely because these environments punish shortcuts. Its platform reads the native OpenText object model directly, rather than exporting to a generic intermediate format that loses relationships along the way. For regulated industries like finance, healthcare, and legal services, that fidelity isn't a nice to have. It's the difference between passing an audit and failing one.

Picking A Migration Suite For SharePoint That Actually Scales
Enterprises comparing a migration suite for SharePoint usually land on a short list of familiar names: ShareGate, AvePoint, and Tzunami among them. ShareGate and AvePoint both do strong work on SharePoint to SharePoint or Microsoft to Microsoft transfers, and they're widely used for good reason. But when the source system predates SharePoint entirely, think file servers, OpenText, Documentum, or Lotus Notes, Tzunami's Deployer tends to be the tool enterprise IT teams reach for instead, since it was built from the ground up to handle non native source formats.

Microsoft itself has confirmed that SharePoint Online supports single files up to 250GB and site collections up to 25TB as of its most recent platform updates. Those limits sound generous, but they mean nothing if the migration tool can't correctly map a decade of nested folder permissions into SharePoint's flatter, list based architecture first.

What A Clean File Server To SharePoint Online Move Looks Like
A well planned move to* migrate file server to SharePoint Online *happens in phases, not in a single weekend cutover. Departments get migrated one at a time, validated, then adjusted before the next group moves. That phased cadence catches structural problems early instead of surfacing them across an entire organization at once.

Tzunami's platform was built around this incremental model, letting IT teams pilot a single department, confirm permissions and metadata landed correctly, then scale the same mapping logic across the rest of the file server. It's a slower start, admittedly, but it avoids the chaos of a big bang migration that breaks links across every team simultaneously.
The organizations that get this right treat the file server not as a burden to eliminate quickly, but as an asset worth mapping carefully before it moves anywhere. Speed without structure just relocates the problem into a more expensive platform.

SharePoint Migration Tools: What Separates the Ones That Work From the Ones That Just Demo Well

Tzunami — Wed, 02 Sep 2026 06:28:32 +0000

Most vendor demos for sharepoint migration tools look nearly identical: a clean dashboard, a progress bar, a success message. What they don't show you is what happens at file number 400,000, when metadata mapping breaks on a custom content type nobody documented, or when permissions inheritance doesn't translate the way the sales deck implies. That gap between the demo and the real migration is where most enterprise projects lose weeks.

This isn't another checklist of generic features. It's a look at how experienced IT teams actually evaluate migration tooling, where the common failure points sit, and what separates tools that handle enterprise complexity from ones that only handle simple ones.

Why Tool Selection Matters More Than Most Teams Expect?

It's tempting to treat migration tool selection as a minor decision compared to the "real" work of planning the move. In practice, the tool you pick determines what's even possible whether permissions migrate automatically or need manual rebuilding, whether metadata maps cleanly or gets flattened into generic columns, and whether a mid-project schema change means starting over or just adjusting a mapping rule.

A common misconception among IT decision-makers is that most sharepoint data migration tool options are functionally interchangeable once you get past the interface. They aren't. The differences show up specifically in edge cases: legacy content with inconsistent metadata, deeply nested permission structures, orphaned files with broken references, and repositories that have been migrated once before and carry the scar tissue of that earlier move. Tools that only get tested against clean, well-organized source data tend to fall apart exactly where enterprise environments actually live.

Running a SharePoint Migration Assessment Before You Choose a Tool

Here's a mistake experienced migration teams see constantly: organizations shop for tools before they understand what they're actually migrating. A proper sharepoint migration assessment auditing file volume, folder depth, custom metadata schemas, permission complexity, and duplicate or stale content should happen before a single vendor conversation, not after.

Why this order matters: the assessment tells you which features are non-negotiable. An organization migrating a relatively flat file share has very different requirements than one migrating a Documentum repository with custom object types and lifecycle states. Choosing a tool first and discovering the gap during the assessment phase almost always means either paying for a second tool or accepting manual cleanup work that wasn't in the original budget.

A frequently overlooked detail: the assessment should also surface content that shouldn't be migrated at all. Every legacy repository accumulates duplicate versions, abandoned drafts, and content nobody has opened in years. Migrating it anyway just because it's there inflates both the timeline and the cost, and it's one of the easiest inefficiencies to eliminate before tool selection even happens.

What Actually Defines the Best SharePoint Migration Tool?

There's no single* best sharepoint migration tool* for every organization. The right choice depends on source system complexity, target environment, and how much manual reconciliation the IT team is prepared to absorb. That said, a few capabilities consistently separate tools that hold up in enterprise conditions from ones that don't.

It's the metric vendors lead within demos, but it's rarely what determines whether a migration succeeds; a fast tool that mishandles permissions just creates a fast mess.

Where Migrations Actually Go Wrong?

Ask anyone who has run a large-scale migration and you'll hear the same recurring issues, regardless of which tool was involved:
Permission inheritance gets flattened. Source systems often use nested, cascading permission models. Tools that don't translate this properly force teams to rebuild access manually usually by over-granting permissions just to stop support tickets, which undermines the point of a controlled migration.

Renditions and versions get dropped. Legacy repositories frequently store multiple versions or file renditions. Migrating only the current version looks complete until someone needs an older version for a compliance or legal request.
Delta migration gets treated as optional. Large repositories change daily. Running one full migration pass and assuming nothing changed before cutover is a common and expensive mistake; a proper delta pass catches drift and keeps source and target aligned.

Validation happens too late. Reconciling file counts and metadata accuracy should happen throughout the process, not just at the end, when discovering a gap means reworking a phase everyone thought was finished.
Tzunami Deployer has been built around these exact failure points across two decades of enterprise migrations automating metadata mapping, permission translation, delta passes, and link resolution as part of the migration itself, with detailed reporting at each phase so IT teams can validate the work rather than discover problems after the fact.

Planning for SharePoint Migration Cloud Scenarios

Cloud migrations add a layer most on-premises comparisons skip entirely. A sharepoint migration cloud project moving into SharePoint Online or Office 365 introduces throttling limits, API rate constraints, and tenant-level configuration decisions that don't exist in an on-premises-to-on-premises move. Migration tools that were originally built for on-prem environments sometimes bolt on cloud support later, and it shows: throttling handling is inconsistent, and large migrations can stall without clear visibility into why.
The practical takeaway for IT teams: when evaluating tools for a cloud destination, ask specifically how the tool handles Microsoft's throttling and rate limits at scale, not just whether it "supports" Office 365. That distinction rarely shows up in a demo but matters enormously once a multi-terabyte migration is actually running.
Frequently Asked Questions

How long does a SharePoint migration assessment typically take?
It depends on repository size and complexity, but most enterprise assessments run from a few days to a few weeks. The time is worth it assessments prevent the tool-selection and budget mistakes that cost far more later in the project.

Do all SharePoint migration tools support permission migration automatically?
No. Automated permission translation is one of the more advanced capabilities, and it varies significantly between tools. This is worth testing directly during a proof of concept rather than taking a vendor's word for it.

Is a faster migration tool always the better choice?
Not necessarily. Speed matters less than accuracy for metadata, permissions, and content integrity. A tool that migrates quickly but requires extensive manual cleanup afterward often costs more time overall than a slightly slower, more thorough one.

What's the difference between a standard migration and a delta migration?
A standard migration moves content once. A delta migration captures and moves only what changed since the last pass, essential for large, active repositories where content keeps changing during a multi-week or multi-month project.