When a content management system is being sunset, the announcement can create immediate uncertainty for the organizations that rely on it. Your website may still be operating normally, but the countdown has begun toward a future without security updates, technical support, compatibility fixes, or continued product development.
A CMS sunset does not necessarily mean your website will stop working on the final support date. It does mean that the risks and costs associated with keeping it online are likely to increase.
Organizations facing a CMS end-of-life announcement should use the available time to evaluate their current website, select a replacement platform, preserve valuable content and search visibility, and complete a structured migration before support disappears.
This guide explains what to do when your CMS is being sunset and how to turn an urgent technology problem into an opportunity to improve your website.
What Does It Mean When a CMS Is Sunset?
A CMS sunset occurs when the company or development team behind a content management system decides to discontinue the platform or a specific version of it.
The sunset process may include several stages:
- New feature development ends.
- Maintenance updates become less frequent.
- Security patches are discontinued.
- Customer support is reduced or eliminated.
- Hosting or cloud services are terminated.
- Documentation and developer resources are removed.
- Integrations stop receiving compatibility updates.
Some vendors provide several years of notice. Others offer only a short migration period, especially when a product has been acquired, merged into another platform, or replaced by a newer cloud-based offering.
Even when the vendor provides an upgrade path, that option may involve a significant rebuild. Moving to the vendor’s newest product is not always simpler than migrating to an entirely different CMS.
Do Not Wait Until the CMS Stops Working
One of the most common mistakes organizations make is treating the sunset date as the date they need to begin planning.
It should instead be treated as the deadline for completing the migration.
A comprehensive website migration may require time for:
- Platform evaluation
- Content inventory and cleanup
- Website design
- Template development
- Custom functionality
- Integration rebuilding
- Content conversion
- Search engine optimization
- Accessibility testing
- Redirect planning
- User acceptance testing
- Staff training
- Launch preparation
Large websites, multilingual platforms, intranets, membership websites, and sites with custom integrations can require considerably more planning than a basic marketing website.
Beginning early gives your organization more control over its technology decisions. Waiting until the final months may force you to accept an expensive vendor upgrade, rush the migration, or continue operating unsupported software.
1. Confirm the Sunset Timeline and Support Terms
Start by reviewing the official end-of-life announcement and identifying the dates that affect your organization.
Important questions include:
- When will feature development end?
- When will security updates stop?
- When will technical support become unavailable?
- Will the CMS continue to run after the sunset date?
- Is the website hosted by the CMS provider?
- Will hosted websites be taken offline?
- Will APIs, integrations, or authentication services remain available?
- Is there a deadline for exporting website content?
- Will documentation and developer tools remain accessible?
- Does the vendor provide an upgrade or migration path?
Do not rely only on the general sunset announcement. Review your organization’s licensing, hosting, and support agreements because your specific deadlines may differ.
Document all relevant dates and work backward to establish an internal migration schedule.
2. Identify the Risks of Remaining on the Platform
A CMS that has reached end of life may continue functioning, but using it becomes progressively more difficult and risky.
Security vulnerabilities
Once security patches stop, newly discovered vulnerabilities may remain permanently unresolved. This can expose your website, customer information, employee data, forms, integrations, and hosting environment to unnecessary risk.
Compliance concerns
Organizations subject to security, privacy, accessibility, or industry-specific requirements may find it difficult to demonstrate compliance while operating unsupported software.
Integration failures
Third-party systems continue to change even when your CMS does not. CRM platforms, analytics tools, payment gateways, authentication providers, browsers, hosting environments, and APIs may eventually stop working with the discontinued platform.
Limited technical expertise
Developers familiar with the platform may move to newer technologies. Over time, finding qualified support can become harder and more expensive.
Increasing maintenance costs
Unsupported systems often require custom patches, workarounds, and specialized hosting configurations. Money that could be invested in a new website instead goes toward maintaining an aging platform.
Content portability problems
The longer you wait, the greater the possibility that export tools, APIs, documentation, and vendor support will become unavailable. Extracting content after a platform has been fully discontinued can be considerably more complicated.
3. Create a Complete Website Inventory
Before selecting a replacement CMS, document what currently exists.
A website inventory should include more than a list of pages. It should identify the content structures, functionality, integrations, and relationships that must be preserved or rebuilt.
Review the following areas:
Content
- Pages
- Blog posts
- News articles
- Landing pages
- Documents
- Images
- Videos
- Staff profiles
- Locations
- Events
- Products
- Resources
- Categories and tags
- Multilingual content
Content structure
- Content types
- Templates
- Components
- Custom fields
- Taxonomies
- Parent-child relationships
- Related content
- Reusable content
- Navigation hierarchies
Functionality
- Site search
- Forms
- Calculators
- Directories
- Document libraries
- Member portals
- Restricted content
- User accounts
- Ecommerce
- Event registration
- Personalization
- Workflows and approvals
Integrations
- CRM systems
- Marketing automation platforms
- Donation platforms
- Payment processors
- Learning management systems
- Membership databases
- Single sign-on providers
- Analytics platforms
- Search services
- Translation tools
- External APIs
SEO data
- URLs
- Page titles
- Meta descriptions
- Canonical URLs
- Redirects
- Structured data
- XML sitemaps
- Image alt text
- Open Graph metadata
- Internal links
This inventory becomes the foundation for platform selection, migration estimates, and quality assurance.
4. Decide What Should Be Migrated
A CMS migration does not require moving every item exactly as it exists.
A platform sunset can be an opportunity to eliminate outdated, duplicated, low-value, or inaccurate content.
Classify content into categories such as:
- Migrate without changes
- Migrate and revise
- Consolidate with another page
- Archive outside the CMS
- Redirect to a replacement page
- Remove entirely
Content decisions should be based on more than age. An older page may still attract search traffic, earn backlinks, provide regulatory information, or support an important customer journey.
Review analytics, backlinks, conversions, content ownership, compliance requirements, and organic search performance before removing content.
5. Export Your Content as Early as Possible
Do not wait until the migration begins to secure a copy of your website data.
Create exports and backups while the original CMS, APIs, vendor support, and administrative tools are still available.
Depending on the platform, content may be accessible through:
- Built-in export tools
- Database exports
- REST or GraphQL APIs
- XML or JSON feeds
- CSV reports
- Vendor-provided archives
- Static HTML crawls
- Custom extraction scripts
Export the content itself as well as associated metadata, relationships, media, files, users, taxonomies, redirects, and SEO fields.
You should also retain copies of:
- Database schemas
- Template definitions
- API documentation
- Integration credentials
- Content model documentation
- Website sitemaps
- Analytics reports
- Existing redirect files
- Server configuration information
Having an independent copy of this information protects your organization if the platform becomes inaccessible earlier than expected.
6. Evaluate Replacement CMS Options
The best replacement is not necessarily the platform recommended by the current vendor.
Evaluate multiple options based on your organization’s actual needs.
Important criteria include:
Content editing
Can nontechnical users create, edit, preview, schedule, and organize content efficiently?
Content modeling
Can the platform support your existing content types, custom fields, taxonomies, and relationships?
Design flexibility
Can your organization create new page layouts without relying on a developer for every change?
Integrations
Does the CMS connect with your CRM, marketing tools, identity provider, analytics platform, search solution, and other business systems?
Security
Does the platform support modern security practices, access controls, logging, multifactor authentication, and a reliable update process?
Accessibility
Can the organization build and maintain an accessible website that supports its compliance goals?
Hosting flexibility
Are you required to use the vendor’s hosting, or can you choose an infrastructure provider?
Data ownership
Can you export your content in a practical, structured format if you need to migrate again?
Developer availability
Is there a healthy ecosystem of developers, agencies, documentation, and extensions?
Total cost of ownership
Consider licensing, hosting, development, maintenance, support, upgrades, integrations, and staff training—not just the initial subscription price.
Popular replacement options may include WordPress, Drupal, HubSpot Content Hub, Contentful, Sanity, or another headless or enterprise CMS. The right choice depends on the size of the website, editorial workflow, security requirements, internal resources, and long-term technology strategy.
7. Determine Whether to Redesign or Rebuild the Existing Experience
A CMS migration and a website redesign can happen at the same time, but they do not have to.
Organizations generally have three options:
Recreate the existing website
The current design and user experience are rebuilt on the new platform with minimal visual changes. This can reduce design effort, but the website may carry forward existing usability problems.
Refresh the website during migration
The organization retains its overall brand and structure while improving navigation, templates, accessibility, mobile usability, and content presentation.
Complete a full redesign
The migration becomes part of a broader website strategy involving new branding, information architecture, user research, design, and functionality.
The best approach depends on the condition of the current website, available budget, deadline, and organizational goals.
When the sunset timeline is short, it may be safer to prioritize migration and schedule broader design improvements for a later phase.
8. Map the Old CMS to the New CMS
Content rarely transfers perfectly from one CMS to another.
Each platform may use different terminology and structures for templates, blocks, modules, fields, taxonomies, media, and reusable content.
A content mapping document defines how the old system will translate into the new one.
For example:
- Legacy page templates may become WordPress block patterns.
- Structured database records may become custom post types.
- CMS components may become Gutenberg blocks.
- Metadata properties may become custom fields.
- Folder structures may become categories or hierarchical content types.
- Shared content may become reusable blocks or global fields.
- Vendor-specific media references may become standard media library attachments.
Mapping should happen before automated migration development begins. Otherwise, content may be transferred into the wrong structures, requiring extensive manual cleanup.
9. Protect Your Search Engine Visibility
CMS migrations can affect organic search performance when URLs, metadata, internal links, content, or page structures change.
SEO preservation should be included in the project from the beginning rather than treated as a launch-day task.
A migration SEO plan should include:
URL inventory
Crawl and export all indexable URLs from the existing website.
URL mapping
Determine the destination for every important URL. URLs should either remain unchanged or redirect to the most relevant replacement.
301 redirects
Implement permanent redirects for URLs that change. Avoid redirecting every removed page to the homepage, which provides a poor experience and weak relevance signals.
Metadata migration
Preserve or improve page titles, meta descriptions, canonical tags, Open Graph metadata, and structured data.
Internal link updates
Update internal links so they point directly to new URLs rather than passing through redirects.
Sitemap generation
Create accurate XML sitemaps and submit them to the appropriate search engine tools after launch.
Analytics continuity
Maintain analytics tracking, conversion events, tag manager configurations, and search console verification.
Post-launch monitoring
Monitor crawl errors, rankings, traffic, redirects, indexation, and server logs after the new website launches.
A structured SEO migration process can substantially reduce the risk of losing visibility during the transition.
10. Plan for Custom Features and Integrations
Some of the most important parts of a website may not be stored directly in the CMS.
Forms may send information to a CRM. A staff directory may pull data from an external database. Members may authenticate through single sign-on. Donations may be processed by another platform.
Document each integration and determine whether it will be:
- Reconnected to the new CMS
- Rebuilt using a new API
- Replaced with a different service
- Consolidated into the new platform
- Retired
Do not assume that existing integration code can simply be copied. Vendor-specific SDKs, authentication methods, field names, webhooks, and data formats may need to be rebuilt.
Integration testing should be included in the project schedule and launch checklist.
11. Build a Migration Quality Assurance Process
A successful migration is not measured only by the number of records transferred.
The migrated website should be evaluated for content completeness, functionality, design accuracy, SEO preservation, accessibility, and performance.
Quality assurance should examine:
- Page titles
- Body content
- Headings
- Images
- Documents
- Links
- Taxonomies
- Custom fields
- Related content
- Author information
- Publish dates
- Meta descriptions
- Canonical tags
- Structured data
- Redirects
- Forms
- Search functionality
- Responsive layouts
- Accessibility
- Page performance
Automated comparisons can identify missing content, altered metadata, broken links, and discrepancies between the old and new websites. Manual review is still necessary for visual presentation, editorial quality, and complex functionality.
12. Train Your Content and Technical Teams
A new CMS changes more than the website’s technology. It changes how employees create, review, publish, and maintain content.
Training should be tailored to different roles:
- Content editors
- Marketing teams
- Communications teams
- Website administrators
- Developers
- IT and security personnel
- Department-level publishers
Provide documentation for common tasks and establish governance rules for page creation, media management, accessibility, SEO, approvals, and content ownership.
The migration is more likely to deliver long-term value when staff understand how to use the new platform confidently.
13. Create a Contingency Plan
Even with an organized schedule, your migration may encounter delays.
Create a contingency plan before the sunset deadline approaches.
The plan may include:
- Extending vendor support
- Purchasing an additional licensing period
- Moving the current CMS to isolated infrastructure
- Creating a static archive
- Exporting critical content to an interim platform
- Launching the new website in phases
- Prioritizing high-value sections first
- Temporarily disabling nonessential functionality
The goal is to avoid reaching the end-of-support date without a secure, accessible website or a recoverable copy of your content.
Questions to Ask a CMS Migration Partner
CMS migrations often involve a combination of content engineering, development, design, SEO, accessibility, infrastructure, and project management.
Before selecting a migration partner, ask:
- Have you migrated websites from our current CMS?
- How will you extract content from the discontinued platform?
- Can you preserve custom fields, relationships, and taxonomies?
- How do you handle media and document migration?
- Will you create a complete URL and redirect map?
- How do you validate migrated content?
- Can you rebuild our integrations and custom functionality?
- How will you protect organic search visibility?
- What will be automated, and what requires manual work?
- Will we receive training and migration documentation?
- Who owns the migration scripts and exported data?
- What support is available after launch?
Look for a partner with experience in both the source and destination systems, especially when the website contains thousands of pages, custom content types, multilingual content, or complex integrations.
A CMS Sunset Can Be an Opportunity
A CMS end-of-life announcement creates urgency, but it can also give your organization the justification it needs to modernize an outdated website.
A carefully planned migration can result in:
- Easier content editing
- Better website performance
- Stronger security
- Improved accessibility
- More flexible integrations
- Reduced licensing costs
- Greater control over website data
- A cleaner content structure
- A more scalable technology foundation
- A better experience for visitors and staff
The key is to begin before the deadline forces rushed decisions.
Plan Your CMS Migration With WordHerd
WordHerd specializes in complex website and CMS migrations, including large websites with thousands of pages, custom content types, structured data, multilingual content, documents, integrations, and SEO requirements.
Our migration process can include content extraction, content mapping, automated conversion, custom development, media migration, SEO metadata, schema, 301 redirects, quality assurance, staff training, and post-launch support.
Whether your CMS is being completely discontinued or your current version is reaching end of life, WordHerd can help you evaluate your options and build a structured path to a supported platform.
Contact WordHerd to discuss your CMS sunset timeline and migration requirements.