5 Tips Before Migrating from OpenText Content Server to SharePoint Online
- 2 days ago
- 6 min read
Many organizations eventually reach the same point with OpenText Content Server. After it has been in place for years, the system holds important business records, project files, contracts, drawings, correspondence, approvals, emails, controlled documents, and historical content. It may also include custom modules, workflows, integrations, inherited permissions, business workspace templates, and add-ons that only a few people still understand.
Microsoft 365 becomes the preferred collaboration platform, as users increasingly work in Teams and SharePoint Online, IT aims to reduce legacy infrastructure, records and compliance teams seek better visibility, and business leaders want easier access to information.
While migrating from OpenText Content Server to SharePoint Online may sound simple, the reality is that the actual work underneath it rarely is. A successful OpenText to SharePoint migration involves understanding what OpenText is doing today, what SharePoint Online can replace, and where another Microsoft 365 or third-party solution may be needed.
Here are five practical tips to consider before starting.
1. Understand which OpenText modules and extensions are being used
It’s important to start by asking the question, “What parts of OpenText Content Server are we actually using?”
Many OpenText environments are more than a document repository. Over time, organizations may have added modules, extensions, viewers, workflow tools, controlled document features, engineering drawing capabilities, integrations, and customizations.
Before designing the SharePoint destination, inventory what is currently in use.
Common examples include:
Brava for viewing and markup
Blazon for rendering and publishing
Workflow for routing, approvals, and task management
XML extensions for custom forms, layouts, or user experiences
Document Control for controlled documents, revisions, approvals, and release processes
Engineering drawings for drawing management, transmittals, revisions, and related engineering records
Business Workspaces for structured content tied to business objects
Custom modules, scripts, web reports, LiveReports, forms, or integrations
This inventory is important because SharePoint Online does not have an exact equivalent for every OpenText capability. Some functions may map cleanly into SharePoint document libraries, metadata, views, content types, retention labels, or Power Automate. Others may require a different Microsoft 365 tool, a custom application, a third-party product, or a decision to retire the function.
Start by extracting a system report from the administration pages and giving it a thorough readthrough to gain a better understanding of the current environment.
2. Look closely at workflows, compound documents, and email folders
OpenText Content Server has object types and behaviours that do not always translate cleanly into SharePoint Online. Three areas deserve special attention: workflows, compound documents, and email folders.
Workflows are usually the first to review
OpenText workflows may support approvals, document reviews, contract routing, onboarding processes, engineering changes, procurement steps, or records processes. SharePoint Online does not automatically become a replacement for those workflows.
Some workflow processes may be rebuilt in Power Automate. Others may belong in another platform, such as a business application, case management system, ERP workflow, or specialized document control tool. Some older workflows may no longer be needed at all.
Compound documents also require attention
OpenText compound documents can represent a group of related documents that behave as a package. Users may see one business item, while the system is managing multiple related components underneath. In SharePoint Online, that model may need to become a document set, a folder, a library structure, a PDF package, or a set of documents connected by metadata.
Email folders need a deliberate plan
Some OpenText environments store emails and attachments in project folders, matter files, contract workspaces, or business workspaces. Those emails may be records. They may also include attachments, conversation context, sender and recipient metadata, and dates that matter for search and compliance.
When migrating email folders to SharePoint Online, the team needs to decide how emails should be stored and displayed. Should they remain as MSG or EML files? Should attachments be extracted? Should emails be migrated to Exchange instead? Should email metadata become SharePoint columns? How will users search and filter that content later?
3. Treat permissions as a design decision, not a copy operation
Permissions are one of the most sensitive parts of any OpenText to SharePoint migration. OpenText environments can include deeply nested permissions, inherited access, exceptions, project-specific restrictions, user-level grants, role-based access, and historical security decisions that are difficult to interpret years later.
It is tempting to copy the existing permissions directly into SharePoint Online, and sometimes that is even necessary for specific content. Legal, HR, finance, contracts, board materials, regulated records, and confidential project files may need strict access controls. Although possible with the help of Peregrine Migrate, copying every OpenText permission exception into SharePoint can create a new environment that is difficult to manage from the first day.
SharePoint permissions work best when they are simple and aligned to business ownership. Before migration, identify the content that truly requires restricted access and then design a SharePoint permissions model that can be explained, supported, and reviewed after go-live. This is also a good time to confirm ownership, as every area migrated should have someone accountable for the content and the access model. Without ownership, permissions become technical debt very quickly.
4. Plan how records will be managed in SharePoint and Purview
OpenText Content Server is often used as more than a document repository, serving as a place where official records are stored, classified, retained, reviewed, and eventually disposed of. Some content may have formal record status while others may be tied to a retention schedule. Some may have disposition history, audit history, holds, approvals, or controlled document rules. It is important to recognize that records context cannot be treated as an afterthought during migration.
SharePoint Online can store the content, but Microsoft Purview is where the records management model needs to be designed. Retention labels, retention policies, disposition reviews, records declaration, file plans, and audit capabilities can all become part of the target solution. The key is to decide how OpenText records concepts will translate into Microsoft 365.
For example, a record classification in OpenText may become a retention label in Purview. A closed project area may become a read-only SharePoint site with retention applied. A controlled document may need a combination of SharePoint versioning, approvals, metadata, and Purview retention. Content that has reached the end of its lifecycle may be reviewed before migration rather than moved by default.
These decisions should be made before the migration build begins, otherwise IT may be asked to move everything first and “figure out records later,” which usually creates more work. Content lands in SharePoint without the right labels, ownership, or lifecycle rules and then records teams need to clean up the target environment after users have already started working in it.
A better approach is to define records treatment rules early.
Which content is an official record?
Which record classifications (RSIs) need to map to Purview retention labels?
Which content should be retained, deleted, archived, or reviewed before migration?
Which sites or libraries need default retention?
Which records require disposition review?
Which audit history must be preserved as evidence?
Not every piece of OpenText records history needs to be recreated directly on the SharePoint item. In some cases, it may be appropriate to retain audit history, disposition evidence, or migration reports separately. In other cases, the information needs to travel with the migrated document as metadata.
The goal is not to make SharePoint and Purview behave exactly like OpenText Content Server. The goal is to create a records management model in Microsoft 365 that is clear, defensible, and manageable after migration.
5. Pay close attention to Business Workspaces and connected systems
Business Workspaces are one of the most important OpenText-specific areas to review before migration. In many OpenText Content Server environments, Business Workspaces are structured work areas connected to business objects, processes, and systems.
A workspace may be tied to a vendor, contract, employee, customer, asset, project, case, purchase order, or engineering object. It may be created automatically from another system or follow a template. It may include standard folders, metadata, permissions, related documents, workflows, and references back to the source business system.
Business Workspaces are often connected to SAP, Salesforce, Workday, Microsoft Dynamics, custom ERP systems, asset management systems, HR systems, or internally built applications. The workspace may exist because another system triggered its creation. Users may enter through that business system instead of browsing OpenText directly.
If any of these connections are ignored, the migrated content may land safely in SharePoint while the business process around it breaks. This is why it is so important to map how Business Workspaces are used before migrating.
Ready to migrate from OpenText to SharePoint?
Migrating from OpenText Content Server to SharePoint Online is not just a content move. The visible result may be a SharePoint site or document library, but the work behind it includes source extraction, object handling, metadata mapping, permission translation, records treatment, workflow decisions, Business Workspace context, integrations, testing, cutover, and reconciliation. This is where Peregrine Migrate can help.
Peregrine is designed to support complex OpenText to SharePoint migrations where the goal goes beyond simply moving files to preserving context and landing content in a Microsoft 365 environment that is usable, supportable, and governed.
A good migration does not need to recreate every historical OpenText decision. Rather, it needs to move the correct content, apply the right structure, and give users confidence in the new destination.
Cadence Solutions helps organizations plan and execute OpenText Content Server to SharePoint Online migrations using Peregrine Migrate and practical Microsoft 365 migration experience.
Learn how Peregrine Migrate helps organizations move from OpenText Content Server to SharePoint Online.