TL;DR:
Before an enterprise SharePoint migration starts, six things need to be mapped: content, permissions, metadata, structure, identity, and links. This guide walks through each mapping layer, what it involves, and what goes wrong when it’s missing.
Most migration plans start with one question: what needs to move? A better place to start is asking what needs to be mapped before anything moves.
Mapping helps determine whether permissions arrive correctly, metadata stays intact, the new structure makes sense, and links users have relied on for years still work after cutover. When these areas are overlooked, the problems usually show up during migration or after go-live, when they’re harder to fix.
Companies that skip the mapping phase don’t save time. They spend it later while reorganizing structure after go-live, remediating permissions that migrated incorrectly, and rebuilding metadata columns that arrived blank because the term store wasn’t ready.
This guide covers the six mapping layers every enterprise SharePoint migration needs before execution begins, what each one involves, where companies most commonly cut corners, and what that costs them.
1. What Are You Really Moving?
Before migration starts, you need a clear picture of the source environment.
It’s easy to assume that everything should move. But older environments often contain duplicate files, outdated documents, unused content, and files that no longer have an obvious owner.
Start by finding out what is actually there.
A content map should help answer:
- What should be migrated?
- What should be archived?
- What can be removed?
- What content needs further review?
Tzunami’s Pre-Migration Analyzer can scan the source environment and provide information such as item counts, file distribution, path length violations, invalid characters, and oversized files.
2. How Should Permissions Map to SharePoint?
Permissions can become complicated over years of changes.
When those permissions are moved to SharePoint, the source security model needs to be mapped to the target.
Before moving anything, ask:
- Which users and groups still need access?
- Where is inheritance broken?
- Are there individual permissions that should be reviewed?
- How will external users be handled?
- Are source and target using different domains?
Tzunami Deployer supports mapping users, groups, roles, and permissions from the source system to the SharePoint security model, including cross-domain scenarios.
3. How Will Your Metadata Translate?
Moving a document without its metadata can mean losing important business context.
The source system may use different fields, values, or structures than SharePoint. Those differences need to be mapped before the content moves.
A metadata map should answer:
- Which source fields map to SharePoint columns?
- Which values need to be mapped or changed?
- Which managed metadata terms need to exist in the target?
- What happens to fields that have no direct equivalent?
Tzunami Deployer supports metadata migration, property mapping, and value mapping, which allows source information to be mapped to the SharePoint target structure.
The point is to preserve the information that makes the file useful.
4. What Happens to the Existing Structure?
A migration doesn’t have to mean copying the existing structure exactly as it is.
A company may have spent years building a folder hierarchy that made sense at the time but is now difficult to navigate.
Before migration, consider:
- How should the source structure map to SharePoint sites and libraries?
- Are there folders that can be simplified?
- Are there long paths or problematic names?
- Should some information be represented through metadata instead?
For example, a file server might organize documents by year → department → project. In SharePoint, that same information could potentially be handled through metadata instead, depending on the requirements.
It’s much easier to make that decision before thousands or millions of items have already been moved.
5. How Will Source Users Map to SharePoint?
Permission mapping and identity mapping are closely connected.
If a source user doesn’t have a corresponding identity in the target environment, their permissions can’t be mapped to an account that doesn’t exist there.
Identity mapping should consider:
- Source users and their SharePoint accounts
- Former employees and inactive accounts
- Source security groups
- Cross-domain environments
- Different identity systems used by legacy repositories
This becomes especially important when migrating from legacy ECM systems, where user management may work differently from SharePoint.
6. What Happens to Existing Links?
This is one of the easiest things to overlook.
When content moves, its URL can change.
That can affect links inside documents, navigation menus, emails, bookmarks, and other systems that point to the old location.
Before migration, consider where important links exist and what users will need after a cutover.
Tzunami’s Link Resolver Service can help address this by redirecting requests from old source URLs to the corresponding migrated location. This can preserve access to content even when the original URL has changed.
For users, the expectation is: the content they already know how to access should remain accessible after the move.
What Happens When Mapping Is Skipped?
Each area creates a different problem when it’s overlooked.
| Mapping area | If it’s overlooked |
| Content | Unnecessary or problematic content gets migrated |
| Permissions | Access doesn’t match the intended security model |
| Metadata | Important business information may not map correctly |
| Structure | Existing organization problems can follow the content |
| Identity | Permissions can reference users or groups that don’t exist in the target |
| Links | Users may encounter links pointing to old locations |
The common theme is: problems are easier to address before migration than after users are already working in the new environment.
How Tzunami Handles Migration Mapping
Tzunami handles these requirements as part of the migration process, rather than treating the project as a simple file transfer.
Depending on the migration scenario, Tzunami supports:
- Pre-Migration Analysis to understand the source environment
- Permission Migration and user/group mapping
- Metadata Migration
- Property and Value Mapping
- Structure mapping
- Link Resolver Service
- Migration from multiple enterprise repositories into SharePoint
This becomes especially important when the source system uses a different content, metadata, or security model from SharePoint. Tzunami supports sources including Documentum, OpenText, Confluence, and file systems for SharePoint migration.
Conclusion
Before anything moves, you need to know how the content, metadata, permissions, identities, structure, and links will map to the new environment.
That’s what mapping provides.
The better those decisions are understood before migration, the fewer surprises there are when users start working in SharePoint.
Start with the map. Then move the content.
Frequently Asked Questions
1. What does mapping mean in a SharePoint migration?
Mapping means defining how source content, permissions, metadata, structure, users, and links will translate to the target SharePoint environment.
2. Why is permission mapping important?
It helps ensure that users and groups from the source environment are mapped to the appropriate security model in SharePoint.
3. Why does metadata need to be mapped?
Source systems and SharePoint may use different fields and values. Mapping helps preserve important business information during migration.
4. Should the existing folder structure always be copied?
No. The existing structure should be reviewed before migration to determine whether it still makes sense for the target environment.
5. How does Tzunami support SharePoint migration?
Tzunami supports source analysis, content migration, metadata and permission mapping, link resolution, and migration from multiple enterprise repositories into SharePoint.
