CMS replatforming: strategies, project phases and benefits

Over time, every organization tends to multiply the CMS platforms it uses due to new functional requirements, technological advancements, urgent business demands, or simply because for a particular project, it was decided to work with a new agency that brought its own technological preferences.

After 8 to 10 years, most large organizations find themselves bearing the costs of maintaining 8 to 12 different technological platforms, distributed across several dozen, sometimes hundreds, of servers. At Jahia, we have seen cases where the number of CMS platforms in use exceeded 30 within a single company. This eventually creates an urgent need to clean up this Kafkaesque setup, rationalize it, and consolidate “everything” onto a single platform. Such projects are often referred to as “replatforming” or, sometimes, “IT consolidation.”

A major technological undertaking, re-platforming can bring significant benefits but requires meticulous preparation and flawless methodology because it does not involve migrating just one system but rather multiple, vastly different systems to this new technological foundation. Each source system has its own unique characteristics, including proprietary data structures.

This article reviews the three main strategies for a CMS re-platforming project, the key steps in its implementation, and the benefits one can expect. But first, what is replatforming ?

What is replatforming?

In short, replatforming is the process of migrating an application or system from an existing platform to a new one, usually cloud-based, with minimal changes to the source code. This approach aims to improve performance, scalability and security, while retaining the application's core functionality.

Aims and basic specifications of application replatforming

Replatforming makes sense for an organization if aiming at : 

• Improved Scalability and Performance: By migrating to a more modern platform, applications can better handle increased workloads and user demands, resulting in enhanced performance and the ability to scale resources as needed.
• Enhanced Security and Compliance: Replatforming allows applications to benefit from the advanced security features of modern platforms, ensuring better protection of data and compliance with current regulations.
• Cost Efficiency: Transitioning to a new platform can reduce operational expenses by optimizing resource utilization and decreasing maintenance costs associated with outdated infrastructure.

Replatform VS Refactor

Refactoring involves a thorough overhaul of the application, rewriting or restructuring its code, for example to take full advantage of cloud-native features. This strategy aims to improve the application's agility, scalability and maintainability, but requires a greater investment in time and resources.

In contrast, replatforming involves migrating the application with minor adjustments to optimize its operation, more and more in cloud environments. This can include modifications to take advantage of managed databases or cloud-specific infrastructure services. 

Replatforming therefore lies between rehosting, which is too lightweight for many projects, and refactoring, which requires considerable resources.

The different website replatforming strategies

0 Migration Strategy

The organization implements the new platform but does not migrate any existing sites to it. The platform is designed exclusively for the future, with a clear before/after approach. Every time a new site is needed within the organization or an existing site requires redevelopment or modernization, it is built on the new platform, ensuring that the older version is phased out or preventing the scope of supported platforms from expanding with uncontrolled new initiatives. This is the most conservative and slowest strategy, spanning a long period but offering the highest security. Once the platform is well-established, organizations may consider “forcing” migrations, especially for small, simple sites, to streamline the landscape of solutions and achieve cost savings.

Partial Migration Strategy

This is the most common strategy, which involves migrating (rebuilding) certain existing sites onto the new platform while immediately excluding others that will never be migrated due to cost or priority considerations and are expected to phase out over time. With this strategy, the focus should primarily be on retiring specific platforms by migrating all sites reliant on them, thus removing those CMS platforms from the supported stack. The choice of platforms to retire may be based on high maintenance costs, difficulty in finding skilled resources, security concerns (some platforms being notoriously more vulnerable than others), or the announced end-of-life of a CMS or the release of a major new version. For instance, many re-platforming projects arose during the transition from Drupal 7 to version 8, as a complete or near-complete rewrite was required. The acquisition of a CMS by another vendor is another common trigger for re-platforming, whether due to the anticipated discontinuation of the product or drastic changes in licensing or support conditions. For those who remember the old days, the acquisitions of RedDot then Vignette by OpenText led to turbulent times for customers. You can find more recent examples with companies deceived by early Headless initiatives coming back to a more stable, comprehensive and controlled environment like Jahia.

Read this use case for a good example of replatforming

Complete Migration Strategy

This is the maximalist strategy, aiming to migrate all the sites the organization wishes to retain onto the new platform to maximize the benefits of the operation by decisively and systematically eliminating other CMS platforms. Migration is, of course, not done all at once, but if the modeling phase, component development, and creation of ready-to-use site templates are well-executed, migrations can proceed at a steady pace. This process also provides an opportunity to modernize some sites at a lower cost by leveraging shared functionalities and gaining better control over graphic design outputs—particularly by using a design system for developing new components.

Key phases of an agile re-platforming project

Assessment phase

The harsh reality is that most organizations cannot accurately determine how many websites and digital projects they operate, how many technological platforms are involved, or even their associated costs. Some initiatives are undertaken by individual departments to meet non-critical needs (this is often where you find numerous small sites built with Joomla, WordPress, or older versions of Drupal, and even more exotic platforms). Other projects are managed by subsidiaries or country offices without centralized reporting or coordination with the corporate IT department. Even the parent company itself typically has a preferred technology, but this rarely hosts all the sites under its umbrella. Sites are often created over time, sometimes without the parent company's knowledge or in defiance of its guidelines.

Conducting an inventory of all Digital Points of Presence (DPPs) - including websites, intranet sites, portals, web applications, and mobile apps served by a CMS - is an essential first step to an effective re-platforming effort. This inventory should cover both internally managed and hosted projects as well as those outsourced. While it is the most tedious step, it is by far the simplest. Even if the re-platforming project is halted later, completing this first phase can reveal significant cost-saving opportunities.

Goals of the inventory :

• Assess existing costs.
• Identify platforms with security risks, at minimum based on the CMS and its version.
• Spot neglected platforms or those rarely updated to evaluate their relevance.
• Eliminate clearly obsolete sites or platforms (these are almost always found by the dozens in large organizations).

Data to collect for each project

The data needed for each project is relatively limited but must be as precise as possible to be useful later, especially in assessing the true operating costs, which tend to be significantly underestimated by functional departments.

Here is a template to gather info about all your projects and start your inventory phase.

Selection phase

Once the inventory is completed and a comprehensive list of sites and web projects is established, the next step is selecting which projects will migrate to the new platform and prioritizing them. Depending on the chosen strategy, this selection may vary significantly.

First, all obsolete websites should be eliminated - those with no traffic or updates for months or even years. This often includes outdated blogs, sites for long-past product launches, pages for one-time events, or short-lived initiatives like sponsorships. The list can be surprisingly long, especially for internal sites launched with enthusiasm but abandoned within six months.

A company like Arkema has launched over 2,700 websites in the last 15 years.

For the remaining sites, migration priorities should consider the following factors:

1. Security

Platforms known for recurring security vulnerabilities should be the highest priority for migration, particularly if they are internally hosted or have incoming connections to the organization's IT infrastructure. This step also provides an opportunity to ensure that sites do not store unnecessary sensitive information and that sensitive data is appropriately protected.

2. Operating costs

 While licensing costs may be consistent, hosting and maintenance expenses can vary significantly, sometimes by a factor of 10, depending on the CMS. Platforms that are expensive to maintain, despite low licensing costs, are prime candidates for migration. Similarly, external site management often shows inexplicable cost disparities, even for the same CMS. Identifying and addressing these outliers can lead to quick wins in cost reduction.

3. Site type and frequency

 Many organizations have numerous simple "blog-like" sites with similar characteristics—technically straightforward and sharing uniform content models and workflows, making them easy to migrate. Mini-sites or landing pages, though graphically diverse, might also fall into this category.

4. Technical simplicity of migration

Content-heavy sites (e.g., knowledge bases, support pages, product documentation) are typically composed of simple pages with structured content that any enterprise CMS like Jahia can easily manage. If unsure, consult the chosen solution provider, whose experts can assess migration complexity and provide tailored guidance.

Each organization must weigh these factors based on its own priorities and identified risks.

Objectives of the selection phase :

• Identify which sites should migrate to the new technological stack.
• Estimate the scope of the upcoming migration efforts.
• Select pilot projects to test the new platform.
• Determine the migration order for selected projects.

Modeling and component sharing phase

Once the migration candidates are finalized, the most critical step begins: modeling and consolidating software components required for recreating and migrating the sites. This phase aims to:

• Map content and its types to prepare import scripts and clean the data if necessary. Reducing the number of content types, even if they become more comprehensive, simplifies future development and code maintenance.
• Identify commonalities across platforms to develop shared components only once. Recreating similar functionalities (e.g., blog management, news modules, image galleries, contact forms) for each project is wasteful. Similarly, advanced features like CRM or DAM integrations should be standardized.
• Centralize content management, including text, images, videos, and files. Managing multiple technologies and instances prevents efficient content sharing. Enterprise CMS platforms like Jahia allow seamless content sharing between sites and support common repositories for content creation and updates, ensuring consistency across all usage points. With intelligent rendering mechanisms, the same content can appear differently based on the site or context.

Implementation phase

The operational implementation phase encompasses a wide array of challenges, risks, and methods. Key lessons and mistakes to avoid include:

• Avoid using the organization’s main or most critical site as the first migration candidate. Complex corporate sites combined with re-platforming intricacies increase risks and delays. Start with smaller projects to build experience and master the platform.
• Avoid over-automation of content transfer. A perfect "magic script" for migrating content across CMS platforms rarely exists. Instead, balance automated processes with manual interventions to ensure success without incurring excessive costs or delays.
• Consider cloud hosting to reduce internal resource demands for maintenance and updates. Platforms like Jahia offer managed cloud services with enhanced reliability and security.
• Prioritize comprehensive training for content creators and site managers who must adapt to the new platform's interface and workflows. A well-prepared adoption plan is essential, even if it slows deployment.
• Use a pivot format for data exports and imports. Rather than direct migrations between multiple systems, exporting to a common format (e.g., CSV) simplifies and streamlines data transformation while allowing cleanup and enrichment.

Benefits of replatforming and technology unification

Controlled development costs

With a unified technology stack, it is easier to find or train external resources, optimize development efforts, and avoid redundant functionality. Frameworks like React, supported by Jahia, ensure flexibility and access to a vast talent pool.

Faster business response times

Pre-built components and site models enable rapid assembly of new sites in days or weeks instead of months. For instance, Jahia’s archiving and templating capabilities allow the quick deployment of pre-configured, ready-to-use sites.

On this point, we'd like to offer you an objective comparison (we didn't originate it) between the main CMS on the market (Wordpress, Drupal, Adobe Experience Manager, Contentful...). On this CMS comparison page, you'll find data derived from the analysis of the Core Web Vitals of websites based on the various solutions. Enjoy your reading!

Centralized component library

A centralized repository of templates, content structures, reusable components, and advanced functionalities reduces redundancy, ensures consistent quality, and simplifies maintenance.

Reduced costs

A CMS like Jahia can manage dozens or hundreds of sites without additional hosting and maintenance costs, unlike disparate platforms with unique expenses.

Enhanced security

Managing a single platform is significantly easier and safer than maintaining multiple systems, reducing vulnerabilities and associated costs.

Improved legal compliance

A unified platform simplifies compliance with legal requirements and reduces risks associated with poorly maintained or unmanaged platforms.

Better governance

Centralizing multiple sites on one platform enhances lifecycle management, administration, auditing, and reporting while reducing resource demands.

Conclusion

Replatforming is, indeed, a substantial investment, with software licensing being a minor portion of the total cost. However, if well-executed, it delivers significant savings through effective site selection and component standardization. Close collaboration with the platform provider is critical to ensure a streamlined migration process and efficient utilization of the new system. Above all, such a project is sometimes the only way to address the more critical risk of current times in IT : cybersecurity.