Le plus grand médias "Pureplayer" du Maroc

When do you need to migrate our of Drupal

360 is a classic example of a media company building and maintaining its own CMS with limited resources. In 2012, we built the first version of 360 while running Adyax, the leading Drupal agency that we sold to the Smile Open Source group in 2018. The initial build was quite typical of Drupal 7, featuring a few content types and supporting one website in two languages with several hundred articles.

Ten years later, the platform housed over 1.4 million articles across five websites. It was forced to go headless because Drupal could no longer serve pages due to severe latency and security issues. The overall system was functional but became prohibitively complex to maintain for the sole CTO+CIO+Developer that 360 had. New features were built outside of Drupal (in pure PHP or WordPress for comments), increasing the technical debt of the platform. Journalists complained about the slow admin interfaces, and the websites were often down as the hosting company struggled to scale such a complex system. The cost of inaction eventually surpassed the cost of potential changes.

The RFP process of selecting the right CMS for 360

In selecting a CMS for 360 media company, we focused on several essential criteria: content editing, multimedia integration (including Twitter and YouTube), image asset management, and workflow control. The CMS needed to be user-friendly, support multi-site management, and feature publication scheduling and SEO optimization. It was also important that the system included A/B testing, analytics, and editorial project management tools like notifications and team coordination. Key technical aspects considered were API quality, ease of migration from Drupal, advanced WYSIWYG capabilities, internal search engine, visitor personalization, and the ability to integrate complex infographics. We also assessed the overall technical complexity and user sentiment towards the system. These factors were chosen to ensure the CMS could efficiently support our operations and adapt to future needs.

We refined the list to 4 CMSes :

1. Arc XP > Because it was powering important media companies, like Le Parisien or Libération in France. Was a SaaS product, built by journalists of the Washington Post
2. Ring Publishing > Part of Axel Springer group, it offered robust range of capabilities including front-end, mobile apps, back-end and was a recognized CMS
3. Hygraph (GraphCMS) > Modern, not media CMS, we selected this smaller then german startup because of the love we have for GraphQL, the flexibility offered in terms of structured content and easiness of building front-end on top of it.
4. Prepr > A small Dutch CMS, less known, but providing a large number of out-of-the-box features for a reasonable price.

We run several demo and Q&A sessions to finally make a collegial decision with all stakeholders: code.store as intergrator, CIO, CEO and editor in chief. Resulting notation gave Arc XP as a winner by a tight margin VS Ring Publishing. Being cheaper than Ring by more than 30% the decision was easy, let's start with Arc XP.

Drupal to Arc XP Migration

We have a detailed article about why and how migrate from Drupal to Arc XP, but the journey started on our end with a full rebranding of 360.

We went from this:

To this:

‍

‍

‍

‍

But the journey wasn't that easy with numerous iterations, disagreement and hours of workshops. We prefered other versions what do you think of them?

‍

We had to learn how Arc XP theming works and understand the capabilities of this renowned CMS. Coming from a Drupal background, it initially felt surprisingly restrictive since we could only modify the backend through configuration. Many features typically found in Drupal, such as comments, quizzes, and voting, were absent from the CMS. However, this is a perfectly normal shift, representing a powerful modern approach to building digital products: a composable, headless architecture built on top of best-of-breed SaaS solutions. You select the best commenting platform, quizzes, and voting systems, and integrate them through a unified React front-end application, potentially with a middleware GraphQL unified graph layer to simplify front-end tasks and mask composability from your developers.

The content migration was a relatively straightforward element of the project, as we migrated from Drupal, a tool our team was well-acquainted with. Drupal’s structured content made it easy to extract data. Most challenges arose from the myriad of small details. We had to build five mobile applications using React Native and connect them to Arc XP (though we now prefer Flutter for many reasons). Building the archive sections was particularly challenging due to the complex structure required by Arc XP. Additionally, incorporating an Arabic version added unforeseen complexities in configuring the Arc XP back-office and search engine. We ultimately implemented Algolia Search for indexing and search queries. The sports site was specifically challenging, as much content (sports results) came from external PHP scripts providing iFrames, which were eventually decommissioned and abandoned.

Furthermore, the way analytics and tracking were set up in Drupal differed completely from the new site. For instance, we removed many paginations, resulting in an immediate loss of page views, which we quickly addressed by entirely rethinking our tracking strategy. This required a lot of additional, unforeseen time.

Despite these challenges, the site went live, journalists were extremely satisfied, and the site no longer experienced downtime. Adding content became easier, and over time, SEO dramatically improved, particularly for Google News, as the website increasingly appeared there.

‍