TL;DR
FileNet, Documentum, OpenText, Confluence, and file shares all have different structures, metadata models, and security architectures. If you treat them as the same migration problem, you might end up with broken permissions, missing metadata, and content that doesn’t work in SharePoint. This blog breaks down what changes by source system and why it is important.
Migrating to SharePoint is one project. But how you do it depends entirely on where you’re starting from.
A migration playbook that works perfectly for a file share migration falls apart when applied to Documentum. A process that handles Confluence well misses entirely what makes FileNet difficult.
According to industry analysis, 52% of companies have three or more ECM, document management, or records management systems running simultaneously. That means most enterprise content migration projects don’t involve one source system. They involve several — each with its own metadata model, its own security architecture, and its own set of quirks that have to be mapped to SharePoint’s model before a single file moves.
This blog walks through the most common source repositories — Documentum, OpenText, Confluence, FileNet, and file shares — what makes each one different, and why those differences determine how the migration needs to be approached.
Why Does the Source System Change Everything?
Every repository was built differently. Documentum was built for compliance-heavy regulated content. FileNet was built for high-volume transactional documents in banking and insurance. OpenText was built for structured enterprise workflows. Confluence was built for team knowledge and collaboration.
Each of those design decisions created a different internal structure, a different way of storing metadata, and a different security model. The translation work between source and destination is the migration.
What Makes Documentum Different to Migrate?
Documentum is one of the most metadata-rich source systems a migration team will encounter. Documents in Documentum are objects with custom types, attributes, lifecycle states, renditions, and version labels that exist outside anything SharePoint natively understands.
The migration challenge here is deciding what to do with the Documentum object model when it arrives in a system that doesn’t have one.
Key considerations for a Documentum migration:
- Custom object types need to be mapped to SharePoint content types before migration begins
- Lifecycle states (draft, approved, archived) need a metadata equivalent in SharePoint or they disappear entirely
- Renditions — multiple format versions of the same document — need a clear handling strategy
- Version labels that are meaningful in Documentum need to survive the migration in a way users can still navigate
Tzunami Deployer supports Documentum migration natively, mapping document types, attributes, and permissions from Documentum’s object model to SharePoint’s content types and columns. The metadata translation happens during migration.
What Makes OpenText Different to Migrate?
OpenText is a family of products — Content Server, Extended ECM, eDocs, LiveLink — and each one behaves differently.
What they share is a node-based content model where everything — documents, folders, workspaces, categories — is a node with attributes. That model has no direct equivalent in SharePoint and requires deliberate translation before migration begins.
Key considerations:
- Workspace structure — needs to be mapped to SharePoint sites or libraries based on how each workspace was used
- Category and attribute metadata — must be translated to SharePoint content types and columns before content arrives
- Permission — OpenText permissions are often more granular than SharePoint supports; decisions about what to flatten need to be made upfront
- Multiple products — Content Server, eDocs, and LiveLink each require separate mapping strategies even when migrating to the same destination
What Makes IBM FileNet Different to Migrate?
FileNet is a high-volume transactional repository — the kind that stores millions of scanned documents, case files, and records in banking, insurance, and government. The volume is only part of the challenge. The structure is the other part.
FileNet organizes content around object stores, document classes, and property templates. None of those map directly to SharePoint. A FileNet document class with thirty custom properties needs a SharePoint content type with thirty corresponding columns — and that content type needs to exist in the target before content migrates, or those properties arrive blank.
Key considerations for a FileNet migration:
- Object stores need to be mapped to site collections or libraries depending on volume and access patterns
- Document classes and property templates need to be translated to SharePoint content types and site columns
- High item counts — FileNet environments commonly hold tens of millions of documents — require a migration tool that handles volume without throttling or timeout failures
- Retention and legal hold markers need to carry forward into SharePoint’s compliance framework
What Makes Confluence Different to Migrate?
Confluence is the outlier in this list. It is a wiki. Pages in Confluence are structured content with embedded macros, inline images, page hierarchies, and space-based permissions. None of that translates directly to SharePoint’s document library model.
The migration question with Confluence is not just “where does this content go?” It is “what does this content become?”
Key considerations for a Confluence migration:
- Spaces need to be mapped to SharePoint sites or communication sites depending on their purpose
- Page hierarchies need to become either nested pages in SharePoint or a flat library with metadata representing the hierarchy
- Macros and embedded content — Confluence-specific formatting that has no SharePoint equivalent — need a clear handling strategy before migration begins
- Page permissions in Confluence are space-based and page-level, which needs translation to SharePoint’s inheritance model
Tzunami Deployer supports Confluence migration, preserving page metadata, created and modified dates, authors, and attachments while mapping space permissions to SharePoint’s security model.
What Makes File Shares Different to Migrate?
File shares are deceptively simple as a source system and consistently underestimated as a migration problem.
There is no metadata model to translate or custom object types. There is no complex permission hierarchy.
Years of folder-based organization that worked on a file share — deep nesting, path-based logic, inconsistent naming — doesn’t work in SharePoint. SharePoint has a 400-character path limit. It has architectural thresholds for item counts per library. It is organized around metadata and search.
Key considerations for a file share migration:
- Deep folder hierarchies need to be restructured — flattened where possible and represented as metadata rather than folder levels
- Path length violations need to be identified and resolved before migration
- NTFS permissions need to be mapped to SharePoint groups — direct user assignments from file shares rarely translate cleanly
- Inconsistent naming conventions accumulated over years need to be standardized before or during migration
How Does Tzunami Handle Multi-Source Environments?
Most enterprise environments have several — the result of years of acquisitions, departmental decisions, and platform changes that never got consolidated.
Running separate migration workstreams for each source system is one of the biggest timeline and budget killers in enterprise content migration. Different tools, different approaches, different validation processes — multiplied by the number of source systems in the environment.
Tzunami Deployer supports over 20 ECM source systems,that means a company migrating from three legacy systems simultaneously runs one migration project, not three. Permissions, metadata, and content structure are mapped from each source to SharePoint’s model through the same tool, with consistent reporting and validation across every source.
The source system changes what needs to be mapped. It doesn’t have to change how the project is managed.
Conclusion
Every source system has a different internal logic. The migration that respects it delivers an environment that works on day one. That’s the only measure of success that matters.
Frequently Asked Questions
- Why does the source system matter so much in a SharePoint migration?
Every source system has a different metadata model, security architecture, and content structure. Applying the same migration approach to all of them means something breaks — usually permissions, metadata, or both. - Can you migrate from multiple source systems to SharePoint at the same time?
Yes — but it requires a tool that supports all of them. Tzunami Deployer supports over 20 ECM source systems from a single interface, so multi-source migrations run as one project rather than several. - What happens to Documentum metadata during migration?
Documentum’s custom object types and attributes need to be mapped to SharePoint content types and columns before migration begins. Without that mapping, metadata arrives blank or is lost entirely. - Why is Confluence migration different from other repository migrations?
Confluence is a wiki, not a document repository. Pages, macros, space hierarchies, and embedded content all need deliberate translation to SharePoint’s model. - What is the biggest risk in a file share migration to SharePoint?
Path length violations and deep folder hierarchies. SharePoint has a 400-character path limit and architectural thresholds for item counts. File shares often violate both — and the violations need to be resolved before migration, not during it.
