Cloud Platform
Content Architecture Considerations for new and migrating Drupal Applications
When building or redesigning a website, teams often hear the phrases "content architecture" and "content model." These phrases mean more than knowing what content is on the site. We define "content architecture" as organizing information that is meaningful and intuitive for site and platform users. We define "content modeling" as documenting the different types of content, and the content's fields, categorization, and taxonomies. This requires figuring out what content you need on your site, and how that content should be built within the website or platform.
A content architecture document will contain each type of content needed on the site, details of all the elements and components of each type, and how each content type is related to the others.
Content architecture is important for several different user groups:
Drupal s ease of use means that content architects can add multiple fields to content types and entities with a few clicks of a mouse. As a result, some content models are overly complicated. A well-defined content architecture sets the development team up to build out the structure that best and most efficiently supports the company s business goals and functionality. Follow the steps below to create the most effective content architecture for your project.
The first step in developing any content architecture involves performing a content inventory. A content inventory, which is a list of all content on the site, will not only assist in determining what content should be on the new site, but also in determining how content should be categorized and how it should be presented to site users. This process will also help determine content that is needed for the site, yet does not presently exist. The effort of formalizing an expected content inventory will facilitate project planning around workflow.
A content inventory should do the following:
After creating a content inventory, you are encouraged to create an editorial calendar. An editorial calendar defines the frequency of content creation, review, separation, or removal (hourly, daily, weekly, monthly, evergreen). The calendar should also list the owner and/or source of each piece of content or content section.
Some editorial calendars are heavily informed by a customer s marketing campaigns. Consider seasonality, regular events, and special events and how they may impact an editorial calendar. Also consider the timing of legal or other types of reviews in determining lead time or the round-trip time of content in the workflow, from initial alignment to publication.
Now that you have a list of content that you want to keep and/or create, it is important to determine how the content fits together on the new site or platform.
The first step is evaluating what types of content should appear on the site. There is not always a one-to-one ratio between content types and content with a specific editorial purpose. Although some content may appear to be disparate or even appear in different places on the site, if the two types of content are similar enough to share many of the same attributes, they may be part of the same content type. However, there are cases where the similarities between the two types of content do not lend themselves to be combined into one content type. The reasons why a developer would not want to combine similar types of content are as follows:
The second step in the process is determining how your content fits together. The development team should ask the following questions:
Once the first two steps are complete, the development team needs to determine the attributes for each content type. Content type attributes are the fields that make up the content type, the taxonomy terms/vocabularies, and the metadata.
It is important to consider the following:
Using a content planning tool such as the Drupal Build Specification template assists with content modeling by supporting these activities in content model development. The content model in the context of the natural flow of content creation:
Note: Custom entities are single units of structured data that are used for persistent storage of content and configuration information.
You should complete the content inventory and editorial calendar steps upon committing to a redesign. These steps take the longest and inform the remaining tasks in the content architecture and content modeling process, and thus, influence the final timeline and budget for the project. Determining content types, their fields and attributes, and how they will be used across the site is an integral part of the discovery process and is an input to the planning and Phase 0 of the project. Finally, a full assessment of content that is new or edited will help to accurately schedule those efforts as part of the overall effort.
IMPORTANT: Decisions related to content architecture and content modeling should be made early and often. Because these decisions affect the technical architecture of the application, any significant changes could cause delays in the project and could turn the content architecture and content model into a moving target rather than a defined model with a clear implementation plan.
It is vital to think about how the content from your former site fits into your new content model. How has your data structure changed from the former site to your new site, and how can you successfully move content from one site to the next? The steps below outline the process to follow:
The migration team should include:
Review the content inventory for the content marked as delete, and manage that content so it is not unintentionally moved over to the new website or platform. This can be done by un-publishing content that will not be migrated prior to performing migration (as long as the migration script ignores unpublished content), or by making adjustments to migration scripts to ignore unpublished or undesired content.
A customer needs to review the fields and attributes for their current site and compare them to their new site or platform. Determine what fields and attributes need to be moved and how they map to the content types/entities, fields, and attributes in the new site or platform.
To properly map the data, you may want to use a spreadsheet that can be shared across the team. The spreadsheet should list out the content types and what fields should be migrated. It should also include where the fields and attributes live in the current system, what they are named, where they should live in in the new application, and what they should be called. If you have unstructured content, this may be more challenging or require more manual work on the part of content creators and editors, since unstructured content can only be machine-migrated to the extent the content follows specific rules.
If you are working with structured content, this process is simpler, and you only need to determine into which new content type/field each field from the old database will be migrated.
An example of structured content mapping is as follows:
The plan should conclude with a determination of which content types are being migrated manually and which are being migrated programmatically; it may be more appropriate for content types with a minimal amount of content or simple content to be migrated manually, as the effort to script the migration may be similar to doing so manually.
For migrating content programmatically from Drupal 7 to Drupal 9+, we suggest using Acquia Migrate Accelerate.
You may also use Drupal's Migrate module. Each content type that is migrated programmatically will need a script. These scripts need to be tested early and often.
A developer or migration specialist needs to dive into details such as:
Cloud Platform