Rethinking the Replatform ‑ Taking Advantage of Drupal’s Features and Flexibility

One of the best parts about working for a digital experience agency is the number and variety of projects we get the opportunity to work on. And while the size and complexity of the digital experience platform projects we work on differ, they’ve offered us the opportunity to learn and discover best practices that others can use to help drive the success of their own projects.

Though the type of client work we take on can vary greatly, some frequent projects we’ve been tasked with are clients looking to switch content management systems (CMS) and clients looking to build multiple websites. From this, we’ve discovered the best way to ensure success involves two key factors: having the correct mindset and the correct approach. 

It’s a Replatform—Not a Lift and Shift

A key part of any digital experience platform (DXP) is a CMS. The CMS serves as a hub to centrally manage content. Over the past several years as clients have built out their DXP, we have seen more and more of them looking to move off of one CMS and onto another. 

Many times, the move is between two different CMS options (e.g. Sitecore to Drupal). Other times, it can be moving from one major version to the next major version of the same CMS (e.g. Drupal 8 to Drupal 9). In both these cases, it’s best to think about the project as a replatform or a rehost, and not as a lift and shift.

The term “lift and shift” can make the project seem very easy. We already have a website over here. We just need to move it over there. That shouldn’t be too difficult. Not only does the term obscure the project’s complexity, but it also misses one of the most important advantages to a project like this. When moving to a new CMS, it’s the perfect time to reassess the goals and requirements.

Discovery Phase

When a project like this comes up, an upfront Discovery phase is key for a successful replatform. The Discovery phase helps the team understand the requirements and learn what works in the current system and where improvements can be made in the new platform.

A key component of the Discovery phase is to perform stakeholder interviews to find out what is and is not working in the current system. If you just “move” everything as is to a new platform, you’re bound to repeat the mistakes and shortcomings of the current system.

We aren’t just concerned with the current system’s mistakes. If the current system has been in use for a number of years, the system’s goals may have changed since it was built. If you are investing in a new platform, you do not want to solve yesterday’s problems.

Platform Audit

In addition to the stakeholder interviews, a full audit of the current platform is also key. Even though the goal is not to recreate the current platform in the new CMS, the architect can learn a great deal from the current platform.

Part of the audit should focus on the custom code that has been written. Often, custom code will contain business logic that is needed in the new platform. Another important part of the audit is understanding how the current platform is used and any workflows that have been created for it. The better the architect understands the current system, the better they can plan for the building of the new system.

Understand the CMS Features and Functionality

One last key point is that the new CMS will have different features and functionality than the current CMS. When moving to the new CMS, you will want to change how the current system is built to take advantage of the strengths of the new CMS. Trying to make the new CMS work exactly like the old CMS will result in a lot of frustration and a poorly-built platform.

Build an Ecosystem, Not a Series of Websites

Whenever you need a system that will support multiple websites, it’s important to approach it as an ecosystem and not just a number of individual websites. Building an ecosystem can be, and often is, a challenge. But done correctly, building an ecosystem results in an easier-to-use and easier-to-maintain system that takes advantage of the CMS.

Building an ecosystem allows you to take advantage of the economies of scale. One way to realize that is to build all of the websites with the same code base. This lets you update the CMS and modules as needed in one place, saving time and resources.

But, you can extend this further. If your platform is built with a component-based approach and you build all the websites using a common set of components, the builds will take less time, as will future updates.

By building a custom theme for each website, but using the same components, you can create different looks to cater to your specific brands. Or, for even more scale, you can build out a common theme to use for all websites and just change colors, fonts, etc. By leveraging the same functionality and components across websites, you can make the platform much easier to maintain and use.

Component Consolidation

One of the main challenges with building an ecosystem versus a series of websites is that doing so requires compromises from the websites owners. It is not uncommon for a client with 10 websites to have hundreds of components and dozens of page templates among the websites.

However, when building the new ecosystem, you should consolidate the components and page templates to reduce the number needed. Without consolidation, the build will cost more and take longer than needed and result in a harder-to-user and harder-to-maintain platform.

This consolidation will require the stakeholders to make compromises as it is not possible to rebuild all of the websites exactly the same with fewer components and templates.

A well-built ecosystem lends itself to be easier to build, use, and maintain. This reduces the total cost of ownership and makes it a better choice than building highly-customized, individual sites.

Flexibility is Key

A new DXP is a large undertaking. Today’s consumers expect a much more personalized and seamless experience across channels. The CMS is a critical piece to providing that flexibility.

One way to provide flexibility in the CMS is by using a component-based approach for the content editors to create content. A component-based approach allows content editors to build pages using a series of components within the CMS rather than having a structured format to the page.

This allows flexibility to build pages tuned to the exact message they are trying to send. When done correctly, it can also speed up the content building process by eliminating the need to have developers involved in the creating and publishing of content.

Component-Based Approach

Component-based approaches are much more common these days, but they’re not always executed well. Having someone experienced with this type of approach is vital to the success of the project.

From a design perspective, striking the correct balance between the number of components and the number of component settings is essential to creating an easy-to-use content editor experience.

From a technical perspective, there are usually a number of ways to execute a component-based approach and pros and cons to each. For example, in Drupal, we can use the Layout Builder module as the foundation for our component-based approach, and it works very well.

As an alternative, we can also use a site-building tool like Acquia Cohesion to execute the component-based approach. Both are solid options with pros and cons depending on the requirements.

A CMS that Provides Data

Another way to provide flexibility is by having the CMS be able to provide data to all of your platforms. Using your CMS as a centralized content source allows each channel to use the content as needed.

Drupal is an example of a CMS that excels in this area. Drupal was built with an API-first mentality, meaning that exposing content using APIs is baked into its fabric. Drupal has several modules that make exposing your content as REST APIs services very easy. Drupal also makes it easy to return that data in a variety of formats, such as JSON and GraphQL, as needed by the system consuming the data.

Mind Over Matter

No two projects are alike. However, your next project can benefit from what we have seen and learned from our projects here at Bounteous. The best way to be successful is to have the correct mindset (“This is a replatform, not a lift-and-shift”) and the correct approach (“Build an ecosystem, not a series of websites”) while focusing on creating a flexible system.