Starting Short:
The primary problem with a monolithic DXP is that you are already starting short by opting for it in today’s digital environment. Because:
With a monolithic DXP, it will be quite difficult to keep up with these changes.
Use of APIs:
A composable DXP uses APIs to:
This allows you to meet the basic demand and excel by launching consistent campaigns that support digital experience on all platforms.
Limited Capability:
More often than not, Monolithic systems make it challenging to:
While the customer expects you to be swift and provide better experiences in real-time monolithic systems, if not designed well can limit businesses to take timely actions.
Relevant Analytics & Reports:
With composable DXPs, you can integrate analytics and reports relevant to your business with ease. This helps in:
Businesses that personalize their customer experience are able to grow. It is important to ask if your business falls in this category.
Baked-In Rigidity:
Monolithic DXPs tend to be a pain for modern developers to handle. This is because:
At the end of the day, this hinders the developers and pace of the project.
Face Changes Head-On:
You don’t have to be afraid of changes if you have a composable DXP to rely on. With composable DXP your business can:
With innovation happening at the speed of light, this allows your organization to always stay ahead of the competition.
Overloading:
Businesses are always trying to grow bigger. Sadly, things might get overloaded as you add more:
With monolithic DXP, you will be left struggling to keep up with these changes.
Ease of Scalability:
A composable DXP allows you to respond to changes quickly. This will allow you to:
All of this can happen whenever there is a market opportunity.
Re-Platforming:
Let’s consider that there will be a new customer channel tomorrow.
In all of these scenarios, you will have to re-platform if you have a monolithic DXP.
Flexibility:
With a composable DXP, you will be able to select the best tool for the job and your business. This means:
Ensure that your customers don’t choose your competitors over you simply because you lack the flexibility to respond to their needs.
In order to build any kind of a website, Drupal presents its friendly and powerful content management platform, Drupal 7. You name it and they have it. From Collaborative Social communities to Blogs and social sites.
Its features include Flexible content, Better theming, accessible administration, and built-in feature of adding images to content. The other features include Automated code testing, Improved database support, Better distribution support.
Speaking of Drupal 9, it isn’t a reinvention of Drupal but has a few major differences which separates it from the rest. The first one being updates of dependencies to versions that stay supported and the second one being Removal of its own code that was disapproved with removal before the release of Drupal 9.
Drupal 9 majorly is the same as Drupal 8.9 (which is the last Drupal 8 minor release), apart from the above mentioned two things.
In one of our earlier blogs Picking The Right Drupal Migration Strategy, we discussed what are the different migration approaches and how this is a good chance to refactor the content structure.
In this blog, we will see practical examples of the above steps in a way that would not be overwhelming for all the stakeholders.
Considered as the building block in structured authoring in Drupal, a content type primarily consists of two important elements.
In a content type, the base configuration defines the default behavior and properties of the content type while they permit the creation of a set of fields that are associated together in a meaningful way.
Taxonomy in Drupal: It is a powerful core module that allows one to connect, relate and classify the website’s content.
Thus, the practice of classifying content i.e. Taxonomy can be used in workflow which will further customize a particular or defined sections of the website with various themes.
We have highlighted the importance of handling the content when doing a migration in our earlier blogs Performing Drupal 9 Content Migration
To understand the content on our site better, it helps to look at the content with a fresh perspective. One of the ways in which it can be done is by categorizing the available content types. Some of the options are mentioned below.
Categorization such as above can help us optimize the target site. For example:
Each content type can be documented through the following
A migration like this is also a good time to revisit the taxonomies, number of users, and roles used in the site and add/remove items as needed.
This is the area where we need to be careful not to assume that everything is needed in the new site. During a Drupal Development site, it is natural for a lot of modules to be added but not used.
We recommend classifying the modules based on MoSCoW rules of prioritization.
The ones that fall under this category are mentioned below.
Modules that are used in Drupal 7 but are not needed in the initial phases of the site and can be included only if needed (like Features, Rules, and Panels), fall in this category. It is because a lot can be achieved with Drupal 9 which was only possible via a contributed module in Drupal 7.
It is important to validate the need for each module (contributed and custom). Besides this, try to have only the minimal modules in Drupal 9 as it eases the maintenance of the site during the longer run.
As far as roles are concerned, below are the recommended steps.
For the content workflow,
The need for media depends on the following:
Based on the above, we can decide if we need to have simple image and video fields to store the media. Another option can be leveraging the media module in a core that allows us to store different types of files in the same field. Custom media types can also be created with metadata.
It’s worth noting that the community has often thought of moving to media as part of the default Drupal install. That being said, it is extremely unlikely that simple file fields will disappear from the core in the foreseeable future. But if you are planning to pick media, you’re in good company.
Check references for more detailed approaches for migrating media
Based on the path we choose, we have some supporting modules.
NOTE: Media Directories module provides only virtual directories and is not physical mapping to actual directories in the file system. Work in progress for the same. There is also work going on to support drag and drop for the media library.
The goal to achieve from field re-engineering is to look at the data types of each field and validate if we are doing justice to them.
Below are some incorrect examples of field types commonly found in Drupal 7.
We can either do the following at the destination site
(or)
This will immensely improve the editorial experience.
Other than the above aspects, it is important to also consider the different integrations available in the current site and how we are going to achieve them in the migrated site.
If these are custom integrations you have written, then you would have to rewrite these modules to be compatible with Drupal 9. That is a much larger topic and beyond the scope of this article.
We must document the above aspects as it clearly says the decision and route we take which would provide clarity for the team working on the migration.