Drupal 9 is a fantastic CMS system because it’s capable of so much in terms of content modelling, content authoring experience, and customizability. Because of this, it has become a desirable content management solution for large organizations with content heavy sites that are in need of replatforming.
Replatforming content can be complicated.
A content heavy site could have thousands of pieces of content which can be categorized into over a hundred different types. Let's imagine a news site with thousands of articles, videos, and classifieds. If we go a level deeper you’ll find reporters and contributors. Go even deeper and you’ll find news teams that reporters belong to. Drupal lets you customize your own content types and their fields. For instance you could define a name and news team field to enter in reporter data. You’ll notice that each of these content types can be associated with one another. By constructing these fields and relationships you’re creating what is called a content model. Sites like our hypothetical news site tend to be very complex in their modelling needs.
For some organizations, it’s also common to have multiple online properties that require access to content: think mobile apps, marketing sites, or online stores.
In my experience with replatforming content heavy sites onto Drupal 9, I’ve noticed a few potential pitfalls. It’s not always easy to anticipate the challenges of content migration, feature development, and team coordination during a shift to Drupal. Major stumbling blocks can arise for all of these things.
Here are some ways to address these challenges early and keep your development project moving smoothly.
Avoid migrating messy content.
Published content, for the most part, stays static. However its structure is dynamic. A content type is likely to have gone through spec and schema changes, and over time, old content become inconsistent with newer content in terms of its structure. Let’s say you made it a requirement that your blog posts must display a topic field. This would be baked into your content model as a required field. However your older posts were all written without a topic. Drupal 9 will validate content entered through the UI based on the content model definition but there is currently no option to perform the same level of validation during a migration. Your old blog posts are migrated in with an empty topic field which then causes an error in the display of that post. Because of this it is important to check for and fix inconsistent data before importing. If faulty data is found after migration, it is a laborious task to target the problem data and fix it.
Do a comprehensive content data audit before migration.
A content data audit is different from the content inventory audit that is conducted as part of a site’s information design, although it can be completed at the same time. Content inventory helps identify, count, and categorize content into logical groupings. In our news site example, we could have 300 news reporters in our content inventory. In a content data audit, on the other hand, we are concerned with the where data comes from, what it affects, and the different facets of a piece of content. For example, the reporter’s name, location, and news team, etc. Performing an audit will reveal how your content types should be created to accommodate data requirements and solidify your content model.
We recommend allocating enough time to take inventory of the legacy content and involve developers in scrutinizing each piece of the data before the migration to ensure the integrity of the migration strategy.
Keep in mind that it's not always possible to capture data for each piece of content. Sometimes you’ll discover that during a data audit, the source data for a field is simply unattainable or does not easily fit into the new content model. Because of this, expect to perform some manual touch up of the content after migration.
Schedule content creation and feature development—and start early.
Simultaneous feature development and content creation are another potential challenge when replatforming large, complex websites.
At a certain point during development, the site will be complete enough to begin the task of entering content that was missed. Content that is being created or edited on the existing live site during migration needs to be entered into Drupal manually. Due to the volume of content, creators will want to get started as soon as possible. However, what does that mean for ongoing feature development?
Think of concurrent development and content entry like moving furniture into a new house and renovating at the same time. It’s important to decide which rooms you’re going to be working on and when. You’ll want to cover furniture to protect it from drywall dust and stay out of the electrician’s way. Similarly, it's important to provide the status of what content has completed entry, what is ongoing, and what has not been started. This will impact how a developer chooses to continue with feature development so as not to interrupt ongoing content entry or accidentally wipe content by performing a necessary modelling change.
Provide the necessary training for content authoring.
Once a content model is defined, content types and their fields can be set up blazingly fast! Content creators will likely receive the changes and learn how to enter content without much help. Drupal 9 is touted for its excellent authoring experience after all. However, when there are custom features, or complex relationships with other content, developers have to be prepared to answer a lot of questions to do with content entry. Reviewing all of these questions and taking time to respond can reduce development velocity. One thing that can speed up site development is providing adequate training for content authoring.
Training authors can be done by entering steps in JIRA tickets or a shared document like a wiki page, then sending them to stakeholders for UAT and review. I’ve found that recorded training videos are the most time efficient. They communicate the step-by-step process without lengthy documentation and allow content creators to follow along. For those more complex features, hold a demo with the whole team. This way, developers that may not necessarily have worked on the feature can also benefit from the knowledge transfer.
Keep all of your project stakeholders informed.
The task of replatforming a project in Drupal isn't all about content and migration. Given the scope of your site, there may be many teams with their own responsibilities. Whether it's the marketing team handling SEO, an internal team building APIs for use with other digital properties, vendors that help with communications to their third party integrations, or legal team and compliance to legal standards, each piece has a role in making up the online business. Identifying these responsibilities and planning for them early will reduce blockers in development, testing, and content entry. For example, you may need DevOps to provide a list of existing URL redirects to bring into Drupal, or perhaps your CORS headers need to be set up for specific origins, or certain integration specific settings require implementation in Drupal as a configuration. This is why it is so important to have and follow a project governance structure.
Think beyond the present moment.
This is a soft skill I cannot stress enough when it comes to replatforming, especially in Drupal where the advantage of extensibility and customizability makes it easy to lose track of what a module does, and where a feature is implemented. The big picture encompasses A LOT. Requirements from multilingual, to moderation, to integrations, and caching, the list goes on. It is all too easy to churn out features and fixes without stopping to think about how they relate to each other and to the bigger picture. Obviously it can be near impossible for a single team member to possess complete knowledge of a project. However with good team practices, such as daily stand-ups and status updates, everyone can stay aware and thus be empowered to ask the right questions from the right people.
Make a replatforming checklist.
Create a checklist for developers and testers. The checklist can include specific terms to describe critical high level features that make up the site such as “translations,” “content moderation,” and “content APIs.” Each of these terms should spark a mode of thinking in a context specific to some business requirement.
As an example, let’s imagine there is a field being added to a content type. Going down the checklist, “translations” would prompt you to ask whether the field should be tested for translatability. “Content APIs” would prompt you to think about whether there are any APIs that may also want to expose this new field. This checklist should help with everything from feature ideation to development to testing. The idea is to trivialize a bit of the thinking process while providing value and mitigating the risk of missing any essential items.
Replatforming can be a big undertaking, but it doesn’t have to be stressful and chaotic. Anticipating potential roadblocks, having a clear project plan, and being transparent across teams are key to keeping your project on track.
Need help replatforming your CMS or rebuilding your website? Get in touch with us or download our free website project planning guide.