Legacy Intranet Migration Guide

Legacy intranets often remain in use long after the technology behind them has become difficult to maintain. What started as a central place for company news, policies, employee resources, and documents may now be spread across outdated software, disconnected file libraries, abandoned department sites, and custom applications that only a few people understand.

Migrating a legacy intranet is an opportunity to do more than replace an old platform. It allows your organization to improve how employees find information, collaborate across departments, manage documents, and complete everyday tasks.

However, an intranet migration can become complicated quickly. Content ownership may be unclear, permissions may have evolved over many years, and important functionality may depend on custom code or integrations that are poorly documented.

This guide explains how to plan and execute a legacy intranet migration while protecting critical content, permissions, workflows, and business processes.

What Is a Legacy Intranet?

A legacy intranet is an internal website or employee portal built on technology that has become outdated, unsupported, difficult to maintain, or poorly aligned with the organization’s current needs.

An intranet does not need to be decades old to be considered legacy. A relatively modern platform may still create problems when it:

• Requires specialized developers for routine updates
• Runs on an unsupported software version
• Depends on custom code with limited documentation
• Has poor mobile support
• Makes internal information difficult to find
• Contains duplicate or outdated content
• Cannot integrate with current business systems
• Creates security or compliance concerns
• Has become too expensive to license or maintain

The defining characteristic of a legacy intranet is not simply its age. It is the gap between what the system currently provides and what employees, administrators, and IT teams need.

Common Legacy Intranet Platforms

Organizations may need to migrate from a commercial platform, an outdated content management system, or a completely custom-built solution.

Older SharePoint Environments

SharePoint has been used for intranets, document libraries, team sites, and internal portals for many years. As a result, some organizations have accumulated numerous SharePoint sites, subsites, web parts, workflows, and document repositories.

Common migration challenges include:

• Older on-premises SharePoint installations
• Classic SharePoint sites
• Custom web parts
• Nested site collections
• Complex permissions
• Deprecated workflows
• Duplicate document libraries
• Inconsistent metadata
• Department sites with different structures

A SharePoint intranet migration requires careful analysis of both content and functionality. Simply copying pages and documents into a new system may preserve many of the problems that made the original intranet difficult to use.

Jive

Jive was widely adopted as a social intranet and collaboration platform. Organizations may still have valuable discussions, employee profiles, groups, announcements, documents, and community content stored within older Jive environments.

A Jive migration may involve mapping:

• Spaces and groups
• Blog posts and discussions
• Employee-generated content
• Comments and replies
• User profiles
• Documents and attachments
• Categories and tags
• Activity streams

Because Jive often contains both formal and informal knowledge, organizations must decide which historical conversations still have business value and which can be archived.

IBM Connections

IBM Connections has been used for enterprise collaboration, communities, wikis, blogs, activities, profiles, and file sharing. Migrating from IBM Connections can be particularly complex because content may be distributed across several interconnected applications.

A successful migration should evaluate the business purpose of each content type rather than attempting to reproduce every feature exactly.

OpenText and Documentum

OpenText, Documentum, and similar enterprise content management systems may serve as both document repositories and employee-facing portals.

These migrations often require detailed planning around:

• Document metadata
• Version histories
• Retention rules
• Access restrictions
• Compliance requirements
• Approval processes
• Records management
• Search indexing

The destination intranet may not replace every records management capability. Some organizations maintain a dedicated document management system while using the new intranet as the employee-facing access layer.

Liferay and Other Enterprise Portals

Liferay and comparable enterprise portal platforms may include personalized dashboards, portlets, user directories, document libraries, and application integrations.

Older implementations can become heavily customized over time. Before migrating from Liferay, determine which portal features employees still use and which were created to solve problems that no longer exist.

SiteExecutive, ColdFusion, and Older CMS Platforms

Universities, government agencies, associations, and larger organizations may have intranets built on discontinued or aging content management systems.

These may include:

• SiteExecutive
• ColdFusion applications
• Older Drupal or Joomla installations
• Proprietary Java or .NET systems
• Sitecore implementations
• Homegrown PHP content management systems
• Vendor-specific portals that are no longer supported

Migrating from these platforms may require direct database analysis, HTML parsing, API development, or custom extraction tools.

Completely Custom Intranet Solutions

Some intranets were designed and developed entirely in-house. These systems may not have standard export tools or a recognizable content model.

A custom intranet might combine:

• Database-driven pages
• Static HTML files
• Network drive documents
• Employee directories
• Internal forms
• Custom search tools
• Authentication systems
• Department applications
• Hard-coded navigation
• Embedded third-party tools

Custom intranet migrations require a discovery process that documents how the current system stores content, authenticates users, controls permissions, and connects with other applications.

Signs That It Is Time to Migrate Your Intranet

Organizations often delay intranet migrations because the existing system still technically works. However, the cost and risk of maintaining it may continue to increase.

Common warning signs include:

Employees Cannot Find Information

Employees may rely on bookmarks, direct links, email attachments, or coworkers because the intranet’s navigation and search no longer work effectively.

Routine Updates Require Technical Support

Publishing a policy update or changing a department page should not require a developer to edit templates, deploy code, or modify the database.

The Platform Is No Longer Supported

Unsupported software creates security, compatibility, and operational risks. Organizations may also find it difficult to hire developers with experience maintaining the platform.

The Intranet Is Not Mobile-Friendly

Employees increasingly expect to access internal information from phones, tablets, and different workplace environments. An intranet designed exclusively for desktop computers can limit adoption.

Content Is Duplicated or Outdated

Legacy intranets frequently contain multiple versions of policies, forms, employee resources, and department information. Employees may not know which version is authoritative.

Maintenance Costs Continue to Rise

Licensing fees, infrastructure expenses, security patches, custom development, and specialist support can make a legacy intranet disproportionately expensive.

The System Cannot Support New Requirements

The organization may need stronger search, single sign-on, document management, personalization, multilingual content, accessibility improvements, or integrations that the existing platform cannot provide efficiently.

Start With Discovery, Not Migration

A successful legacy intranet migration begins with discovery. Before selecting a platform or moving content, document what the current system contains and how employees use it.

Discovery should include interviews with:

• Executive stakeholders
• IT and security teams
• Human resources
• Communications teams
• Department content owners
• Intranet administrators
• Records management teams
• A representative group of employees

The goal is to understand both the technical system and the employee experience.

Questions to answer include:

• What is the intranet’s primary purpose?
• Which content is most frequently accessed?
• Which departments manage content?
• Which features are business-critical?
• Where are documents stored?
• How are permissions assigned?
• Which systems connect to the intranet?
• What complaints do employees have?
• What content must be retained?
• What can be archived or deleted?
• How will migration success be measured?

Discovery prevents the new intranet from becoming a visual redesign of the same underlying problems.

Conduct a Complete Content Inventory

A content inventory identifies what exists before migration decisions are made.

Your inventory may include:

• Pages
• News posts
• Announcements
• Policies
• Procedures
• Employee resources
• Department pages
• Forms
• Documents
• Images
• Videos
• Directories
• Events
• FAQs
• Links to external systems
• Embedded applications
• Discussion content

For each item, capture relevant information such as:

• Current URL or location
• Content type
• Title
• Owner
• Department
• Last modified date
• Publication status
• Permission level
• File type
• Metadata
• Migration recommendation

Each item can then be categorized as:

• Migrate
• Rewrite
• Consolidate
• Archive
• Delete
• Review with the content owner

This process reduces unnecessary content and helps establish a cleaner foundation for the new intranet.

Identify Content Owners

One of the most common legacy intranet problems is unclear ownership.

A page may have been created years ago by an employee who has since left the organization. Departments may assume someone else is responsible for maintaining policies or employee instructions.

Assigning an owner to each major content section helps answer three important questions:

1. Is the information still accurate?
2. Should it be migrated?
3. Who will maintain it after launch?

The migration is also an opportunity to establish publishing workflows, review schedules, and expiration policies so the new intranet does not accumulate outdated information as quickly.

Design the New Information Architecture

Do not automatically recreate the legacy intranet’s navigation.

Older intranets are often structured around organizational charts, technical limitations, or historical decisions rather than employee needs. A modern information architecture should reflect the tasks employees are trying to complete.

Potential top-level sections might include:

• Employee Resources
• Human Resources
• Policies and Procedures
• Departments
• Forms and Documents
• News and Announcements
• Training
• Benefits
• IT Support
• Staff Directory

Navigation should be supported by consistent naming, useful categories, strong internal search, and contextual links between related resources.

Card sorting, employee interviews, search analytics, and usability testing can help determine how employees expect information to be organized.

Map Legacy Content to the New Platform

Once the new content model has been established, create a mapping document that defines where each legacy content type will go.

For example:

Mapping helps developers build repeatable migration rules instead of manually recreating every page.

It also exposes content that does not fit cleanly into the new structure and requires additional review.

Preserve Permissions and Access Controls

Intranet content is not always available to every employee.

Your legacy platform may contain content restricted by:

• Department
• Office
• Region
• Job role
• Leadership level
• Employment status
• Project team
• Membership type

Permission requirements should be documented before migration. Avoid copying complicated permission structures without reviewing whether they are still necessary.

The new intranet may use:

• Role-based access control
• Group-based permissions
• Identity provider groups
• Content-level restrictions
• Private document libraries
• Personalized dashboards

Permission testing should be included in quality assurance. It is not enough to confirm that authorized users can access content; the team must also verify that unauthorized users cannot access it through search, direct URLs, APIs, or document links.

Plan Single Sign-On and User Management

Most modern intranets use single sign-on to provide secure access without requiring employees to maintain another password.

Common identity providers include:

• Microsoft Entra ID
• Okta
• Google Workspace
• OneLogin
• Auth0
• Other SAML or OpenID Connect providers

Single sign-on planning should address:

• Login and logout behavior
• User provisioning
• Group synchronization
• Role mapping
• Account deactivation
• Multi-factor authentication
• External users
• Contractors
• Session duration
• Emergency administrator access

Authentication should be designed early because it can affect permissions, personalization, testing, and launch planning.

Migrate Documents Carefully

Documents are often the largest and most complicated part of an intranet migration.

A document migration may involve:

• PDFs
• Word documents
• Spreadsheets
• Presentations
• Images
• Videos
• Forms
• Templates
• Archived records

Before moving documents, determine whether the new intranet will store them directly or connect to another repository such as Microsoft 365, Google Drive, Box, or a dedicated document management system.

Document migration planning should consider:

• File names
• Folder structures
• Metadata
• Categories
• Version history
• Duplicate files
• Broken links
• Restricted documents
• Retention requirements
• Search indexing
• File previews
• Download permissions

Documents should not simply be placed into a new collection of folders. Applying consistent metadata can make them much easier to search, filter, and maintain.

Rebuild Search Around Employee Needs

Search is one of the most important intranet features, particularly when migrating thousands of pages and documents.

A modern intranet search experience may need to index:

• Pages
• News
• Documents
• Policies
• Staff profiles
• Department information
• FAQs
• Events
• Custom content types

Useful search features may include:

• Filters by content type
• Department filters
• Document type filters
• Date filters
• Keyword relevance
• Synonyms
• Suggested results
• Featured results
• Typo tolerance
• Access-aware search results

Search should respect permissions. Employees should not see restricted content in results, previews, or autocomplete suggestions.

During testing, use real employee search terms rather than relying exclusively on technical test queries.

Document Workflows and Integrations

Legacy intranets often contain functionality that is easy to overlook during a content-focused migration.

Examples include:

• Approval workflows
• Employee onboarding processes
• Internal request forms
• Help desk integrations
• Calendar feeds
• HR system connections
• Learning management systems
• CRM integrations
• Employee directory synchronization
• Emergency notifications
• Expense or travel requests
• Embedded reporting dashboards

For each integration, determine whether it should be:

• Rebuilt
• Replaced
• Integrated
• Simplified
• Retired

Rebuilding an outdated workflow exactly as it exists may not be the best use of the migration budget. In many cases, the process itself can be improved before it is implemented on the new platform.

Build for Accessibility and Mobile Use

An intranet should be usable by employees with different devices, abilities, and working environments.

Accessibility planning should address:

• Keyboard navigation
• Screen reader compatibility
• Color contrast
• Form labels
• Heading structure
• Alternative text
• Accessible documents
• Video captions
• Focus states
• Error messaging

Responsive design should also be tested across desktop computers, tablets, and mobile devices.

Mobile support is particularly important for employees who work in the field, travel frequently, share workstations, or do not spend their day at a desk.

Choose the Right Migration Method

The best migration method depends on the legacy platform, available export tools, content volume, and quality of the source data.

API-Based Migration

An API can provide structured access to pages, users, documents, metadata, and relationships. This is often the preferred approach when the source platform offers a complete and reliable API.

Database Migration

Direct database access may be required for custom systems or platforms without adequate export tools. The migration team must understand the database schema and how records relate to one another.

File Export Migration

Some platforms can export content as XML, JSON, CSV, ZIP archives, or other structured files. These exports can then be transformed and imported into the destination platform.

HTML Crawling and Extraction

When no API or usable database access exists, content may need to be extracted from rendered HTML pages. This approach requires rules for identifying titles, body content, navigation, metadata, attachments, and page relationships.

Hybrid Migration

Complex intranets often require multiple methods. Pages may come from an API, documents from a file export, employee data from an identity provider, and custom application records from a database.

The extraction method matters less than the accuracy, repeatability, and validation of the final result.

Test the Migration

Automated migration does not eliminate the need for quality assurance.

Testing should cover:

• Content accuracy
• Formatting
• Images
• Documents
• Internal links
• External links
• Metadata
• Categories
• Search results
• Permissions
• SSO
• Forms
• Integrations
• Mobile layouts
• Accessibility
• Browser compatibility

Large migrations should use automated comparison tools wherever possible. Automated checks can identify missing pages, broken links, mismatched titles, failed media, incomplete metadata, and other inconsistencies across thousands of records.

Manual review should then focus on representative content types, high-value pages, restricted sections, and complex functionality.

Plan Redirects and Legacy URLs

Although intranets are not always publicly indexed, employees may have bookmarks, saved links, email references, training materials, and documentation that point to legacy URLs.

Create a redirect plan for frequently used pages and documents whenever the destination platform supports it.

For links that cannot be redirected automatically, consider:

• Updating internal links before launch
• Creating a temporary legacy link lookup
• Publishing a list of relocated resources
• Monitoring failed URL requests
• Updating employee training materials
• Maintaining a read-only archive during transition

Preserving link continuity reduces confusion and support requests after launch.

Prepare Employees for the New Intranet

The technical migration is only part of the project. Employee adoption determines whether the new intranet succeeds.

A launch plan may include:

• Early stakeholder demonstrations
• Department previews
• Employee usability testing
• Content editor training
• Quick-start guides
• Short training videos
• Launch announcements
• Office hours
• Feedback forms
• Post-launch surveys

Explain what is changing, why the migration is happening, and how the new intranet will make everyday tasks easier.

Common Legacy Intranet Migration Mistakes

Migrating Everything

Moving every outdated page and duplicate document creates a new intranet with old problems. Complete a content review before migration.

Recreating the Existing Navigation

The legacy structure may reflect years of organizational changes and temporary decisions. Design navigation around employee tasks instead.

Ignoring Permissions Until the End

Permissions can affect architecture, authentication, migration rules, search, and testing. Address them early.

Underestimating Custom Functionality

A seemingly simple intranet may contain forms, scripts, integrations, directories, or workflows that are not visible during a basic content crawl.

Treating Documents Like Attachments

Documents need metadata, ownership, search rules, access controls, and retention planning.

Launching Without Governance

Without clear ownership and review processes, the new intranet will eventually develop the same content quality problems as the old one.

Why Consider WordPress for a Modern Intranet?

WordPress can provide a flexible foundation for organizations replacing legacy intranet platforms or custom internal systems.

A WordPress intranet can support:

• Custom content types
• Department-specific sections
• Single sign-on
• Role-based access
• Searchable document libraries
• Employee directories
• News and announcements
• Internal forms
• Multilingual content
• Workflow integrations
• Responsive design
• Accessible page templates
• Familiar block-based editing

Unlike a rigid, proprietary platform, WordPress can be customized around the organization’s content, users, permissions, and internal processes.

Organizations can also separate the employee-facing intranet from specialized systems used for document management, HR, CRM, learning, or records retention.

Learn more about planning a WordPress intranet migration.

How WordHerd Approaches Legacy Intranet Migration

WordHerd helps organizations migrate complex intranets from commercial platforms, outdated content management systems, and custom-built solutions.

Our process can include:

• Legacy platform discovery
• Content inventory and auditing
• Database and API analysis
• Information architecture planning
• Custom content mapping
• Page and document migration
• Metadata transformation
• Single sign-on implementation
• Permission configuration
• Search development
• Custom functionality
• Redirect planning
• Automated quality assurance
• Accessibility testing
• Editor training
• Post-launch support

Each intranet migration is designed around the source platform and the organization’s actual requirements. We do not rely on a generic content import that treats every page, document, and department the same.

Legacy Intranet Migration Checklist

Before beginning your migration, confirm that your organization has addressed the following:

• Defined the purpose of the new intranet
• Identified project stakeholders
• Completed a content inventory
• Assigned content owners
• Documented permissions
• Evaluated documents and file libraries
• Identified integrations and workflows
• Selected a destination platform
• Designed the information architecture
• Created content mapping rules
• Planned SSO and user management
• Established a testing process
• Created a redirect strategy
• Developed employee training
• Defined post-launch governance
• Established measurable success criteria

Build a Better Intranet, Not Just a New One

A legacy intranet migration should not be treated as a simple platform replacement.

It is an opportunity to eliminate outdated content, simplify permissions, improve search, modernize internal workflows, and give employees a more reliable way to access organizational knowledge.

By combining careful discovery, structured content mapping, automated migration, and thorough quality assurance, organizations can move away from aging SharePoint environments, Jive, IBM Connections, proprietary CMS platforms, and custom intranet solutions without losing the information and functionality employees depend on.

WordHerd can help assess your legacy intranet, develop a migration strategy, and move your content into a modern, maintainable platform built around your organization’s needs.