Code Enigma was engaged by Haymarket Automotive in 2023 to review a Drupal estate that had drifted: four sites, each on a different Drupal and PHP version, none of them supported, and none of them maintainable by a small in-house team. The recommendation was a hybrid route — consolidate the non-decoupled sites onto a single Drupal 10 multi-site codebase, and for What Car?, preserve the existing decoupled architecture while upgrading every component underneath it.
What Car? was the first site taken through that programme because it carried the most commercial value. The work involved standing up a new Drupal 10 multi-site platform and CI environment on AWS, rebuilding the editorial CMS and its custom modules, writing a fresh migration for a very large and unusually tangled content set, and re-pointing a set of live integrations — car data feeds, search, image ingest, user accounts, syndication, and advertising — at the new platform without a visible break at the front end.
About the project
The situation
Haymarket's automotive estate ran four Drupal sites on four versions: What Car? (Drupal 8.6.10, PHP 7.2.34), Autocar (Drupal 7.73, PHP 5.5.9), Classic & Sports Car (8.6.10) and Move Electric (9.2.7). What Car? was itself a set of services, each with its own repository, runtime and release cycle.
Goals
- Move every component to a supported version and drop obsolete libraries.
- Simplify and standardise the architecture without discarding working investment.
- Make it maintainable by a small in-house team, and fast enough to ship features again after years of "keeping the lights on".
Requirements — the integrations
This was never just a CMS upgrade; Drupal had to keep feeding live systems:
- Two front-ends: a legacy React 16 app (~170k lines plus 50 internal dependencies) and its Next.js replacement (~125k lines), both needing a predictable content API throughout.
- A Node.js search aggregation API (~25k lines on Lambda/API Gateway) merging CMS content with vehicle data. It has no delete operation — deletions rely on a nightly full re-ingestion, which constrained the migration and the new content model.
- The Car Buying Engine: nightly CAP deliveries, daily image ingest to S3, star ratings, leasing rates and a mystery-shopper price round-trip, ~24k lines across five nested projects on MongoDB.
- A change of data provider: mid-programme, CAP was replaced by Autotrader — a large commercial saving against a large integration cost. CAP-only concepts such as engines and trims had to be derived from Autotrader derivative terms with no stable identifiers, adding implementation and a substantial data migration.
- New Car Buying: a React/Node/MongoDB/Cognito marketplace on its own domains, using the same vehicle data.
- Syndication: an Elasticsearch JSON API for partners plus an XML/RSS slideshow feed for MSN.
- User accounts via Motoreasy, reinstated late after being descoped then re-scoped.
- Advertising and analytics, with requirements that evolved up to launch.
- SEO and redirects: a redirect map treated as business-critical and handed over immediately before go-live, on a site that had previously lost organic visibility through a botched migration.
Scale of the content migration
Seven content types — the review type alone carried 88 fields — over 22,800 articles, 1,100 used reviews, 735 reviews, plus awards, hubs and authors. Fourteen taxonomy vocabularies held the vehicle taxonomy (55,000 derivatives, 20,000 trims, 8,000 engines), several synced from the provider. Around 82,000 files and 96,000 media entities sat in S3; custom code was nine modules and ~19,000 lines. The site served ~120,000 vehicles, 7,500 with version review pages.
Because a complex Drupal site can't simply be upgraded across major versions, the migration was written rather than clicked: Migrate API with Migrate Plus and Tools, plus custom plugins for vehicle data, media and taxonomy. Content was restructured on the way across — content types standardised between What Car? and Autocar, and vehicle data moved out of taxonomy terms into purpose-built entities.
Outcomes
- A decoupled Drupal 10 editorial CMS on a supported PHP runtime, serving the existing front-end through the same API contract.
- A Drupal 10 multi-site base so Autocar, Classic & Sports Car and Move Electric follow onto one codebase with separate databases, config and files.
- New AWS infrastructure: staging and live autoscaling groups, containerised services, a managed NGINX proxy tier, CI in place, Windows proxy layer retired.
- Vehicle data re-sourced from Autotrader with the saving realised, engines and trims derived from derivative data.
- One editorial platform across titles, fewer codebases to patch, a roadmap the in-house team can own.
- Ongoing managed hosting, DevOps and Drupal support from Code Enigma.
Technical specification, Drupal version
Legacy platform (at audit): Drupal 8.6.10, PHP 7.2.34, decoupled. Front-end in React 16 and Next.js; search aggregation API in Node.js; vehicle data in MongoDB; New Car Buying and syndication on React, Node.js and serverless AWS services; files and media in S3 via the S3 File System module.
New platform: Drupal 10, PHP 8.1+, delivered as a Drupal 10 multi-site codebase with separate per-site databases, configuration and file directories. Editorial CMS remains headless, exposing content to the JavaScript front-end and to the search aggregation API; custom api_entities and api_queue modules handle the queueing and pushing of entity changes.
Infrastructure: AWS — ECS with Fargate for containerised services, Application Load Balancers with target groups, CloudFront with WAF, S3 for assets, Route 53 for DNS, and EC2 autoscaling groups for the front-end proxy tier. Separate staging and live autoscaling groups, continuous integration in place, and configuration managed per environment.
Development tooling: local development via Code Enigma's container-based environment (ce-dev), Git with Bitbucket, pull-request based review with automated tests, Jira for delivery tracking.
Why Drupal was chosen
Drupal was already the CMS of choice across Haymarket's automotive titles, and What Car?'s editorial team had been using it for around fifteen years — so the question was never really "which CMS", but "which architecture". The 2023 roadmap weighed three options and recommended the hybrid: keep Drupal, and use Drupal 10 as a single shared codebase to reverse years of version drift.
The reasons for staying on Drupal were practical:
- Editorial familiarity.
- One platform instead of four, it collapses that maintenance burden onto a small team.
- Security and supportability: Moving to a supported Drupal 10 with a modern PHP runtime was a compliance requirement as much as a technical one.
- Structured content that can be served headlessly: What Car?'s front-ends are JavaScript applications, not Drupal-rendered pages. Drupal's entity model, revisions, taxonomies and JSON/API capabilities let the CMS remain the authoritative editorial source while the presentation layer stays free to iterate independently.
Standardisation across titles. Unifying content types and taxonomy between What Car? and Autocar was a stated goal, and Drupal's configuration management makes that tractable rather than theoretical.
Technical Specifications
Drupal version:
Migrate Plus and Migrate Tools. The existing content could not be upgraded across major versions, and the vehicle data, media and taxonomy relationships had no straight equivalence on the new platform. Drupal's migration framework gave a scripted, repeatable, re-runnable route across, with custom plugins where the mapping was not one-to-one — and it is the same tooling Code Enigma uses on every large migration, so the patterns were already proven.
Paragraphs and Entity Reference Revisions. What Car?'s review and article content types run to dozens of fields each. Paragraphs let the editorial team compose pages from reusable components rather than filling in an 88-field form, and it is the same pattern being applied across the other Haymarket titles — which is what makes a shared content model across sites possible.
Core Media plus S3 File System. With roughly 82,000 files and 96,000 media entities, keeping assets out of the application server and in S3 was the only sensible option. Core Media replaced the deprecated Media Entity contrib module, removing one of the audit's identified blockers to Drupal 10.
Metatag, Pathauto, Redirect and Simple XML Sitemap. What Car?'s organic performance matters commercially and had been damaged by an earlier migration elsewhere in the estate. These modules make SEO a configuration concern rather than a per-page editorial one, and they gave a controlled way to land a redirect map at go-live.
Scheduler rather than lightning_scheduler. The legacy site depended on a Lightning component with no Drupal 10 release; moving to Scheduler with content moderation integration was a required substitution to get onto a supported release.
Config Split and Stage File Proxy. A multi-site codebase with per-environment differences needs configuration that can diverge safely, and development environments that do not require copying the entire asset library.
The custom api_entities and api_queue modules. Because the CMS is headless, content delivery is not a theming problem — it is a queueing and API problem.
Rebuilding these for Drupal 10 was the thing that allowed the existing front-end to keep working unchanged.
No theme, no distribution. The public presentation layer sits outside Drupal by design. Introducing a distribution would have forced a rendering model onto an architecture deliberately built without one.
