Why replatform into Drupal and what X to Drupal provides

Replatforming into Drupal hands your content back to the people who own it. It has also always been priced like a rebuild, because the design and the content model both got recreated by hand. X to Drupal is our harness for doing that work from the rendered site itself. This post covers why the move is worth making and what the harness provides.

The short version

• Replatforming into Drupal is worth it because it turns your site into structured content your team can edit, reuse, govern and report on without a developer in the loop.
• It has always been quoted like a rebuild: the design gets re-implemented by hand and the content model gets invented from scratch.
• Your existing site already holds both answers. They sit in the rendered pages, waiting for something that can read them out at production quality.
• X to Drupal reads the rendered site, derives the content model to a senior architect's standard, and verifies the result against what actually renders.
• What you receive is standard Drupal: typed fields with native widgets, Views for listings, real taxonomies, and zero custom modules.

I have sat in the meeting where a client asks why moving their site to a new platform costs about the same as building it the first time. It is a fair question. The design already exists. The content already exists. And yet the quote covers weeks of design implementation and weeks of content modelling, as if none of it had ever been done.

The honest answer has two halves. The move is worth making, for reasons that compound every year you run a content-heavy site. And the price has been a rebuild price because, until now, a rebuild is what the work amounted to. This post covers both halves, and what our harness, X to Drupal, changes about the second one.

Why replatform into Drupal at all?

A site on a real CMS hands control back to the people who own the content. Your marketing team publishes without a release. Your editors build a campaign page from existing components on a Tuesday afternoon. Your content gets structured well enough to be reused, translated, scheduled and reported on. Governance stops being a spreadsheet and becomes roles, permissions and review states in the platform.

Drupal's central idea is that content is structured data first and a page second. Content types and fields describe exactly what a case study is. Paragraphs let editors compose page narrative from typed components, so an editor sees an image upload and a link field with the widgets Drupal already provides. Views turns any list of content into a configured listing with filters and pagination, so a new insight article appears on the listing, in the related block and in the sitemap without anyone touching a template. Taxonomies give you real categorisation to filter and report on.

Drupal 11 and Drupal CMS ship a great deal of this ready made. Recipes install and configure whole capabilities in one step. SEO tooling, media handling and scheduling are available on day one, already configured. A modern Drupal install starts much closer to finished than it did five years ago.

There is a newer reason too. Structured content is what LLMs can actually read and cite. A site whose pages are typed entities with clean markup and real metadata is far easier for an assistant to quote accurately than a pile of rendered divs. The series covers this in what makes a Drupal site readable to LLMs.

Site builders like Webflow and Framer are genuinely good at what they do, and for a marketing site with a small team they are often the right call. The trade flips at a predictable point: when your content becomes an asset you want to model, query and reuse, the CMS earns its keep.

Why has replatforming always been priced like a rebuild?

Strip out project management and QA, and a typical replatform breaks into four buckets: design implementation, content modelling, content migration, and everything else (menus, redirects, forms, search, SEO metadata, integrations, permissions).

Three of those four buckets are transcription. The information already exists in a form a person can read. It just does not exist in a form the new platform can consume, so people have re-created it by hand.

The design gets rebuilt even though it already exists. Every rendered page carries the design in full: the spacing, the type scale, the breakpoints, the colours, the layout behaviour. A developer rebuilding that page reads those values off a screen with their eyes and types them back in, which is slow and lossy. The creative decisions were made years ago. What remains is data entry with very high standards.

The content model gets invented from scratch, and it is the harder half. A rendered page tells you what it looks like. It does not tell you that these three cards are a listing of a repeating content type, that this band is global chrome shared by every page, that this heading and image belong to one repeatable component. Those are architectural judgements, and they separate a site an editor can run from a pile of pages an editor can only look at. Get the model wrong and editors ask for a "small change" and get a developer ticket, a new landing page needs a deployment, and everyone slowly stops using the CMS.

The person who can make those judgements is the scarcest person in the building. A senior architect who knows Drupal deeply can make the few hundred modelling decisions well, and every one of them is already committed to something. So migration work gets staffed with whoever is available, the visual layer comes out fine because it is easy to check with your eyes, and the content model comes out shaky because nobody sees it until an editor tries to use it six months later.

That is why a replatforming quote has looked like a rebuild quote. The work really was a rebuild, performed by people transcribing information the site already contained.

What X to Drupal provides

For the price to change, the work has to change. Three things would have to happen: something reads the visual layer off the rendered site with real precision, something derives the content model to a senior architect's standard, and something verifies the result against what actually renders. We went looking for a system that does all three, found excellent tools for pieces of it, and nothing that takes an arbitrary live website and produces a Drupal site with both the visual result and an architect-grade content model.

So we built X to Drupal. Here is what it provides.

It reads the design off the rendered site. The harness works from the pages your visitors actually see. It studies the design system the way an architect would and reproduces it as components in the Drupal theme. The old site stays exactly as it is; it becomes the specification.

It derives the content model to an architect's standard. Page narrative lives in ordered paragraph components with typed fields, so an editor sees a heading field, an image upload, a link field and a repeatable group, each with its native widget. Any list of existing content becomes a View. Global chrome such as the header, footer and menus lives in blocks placed in theme regions. Categorisation uses real taxonomy vocabularies with real terms. These are the same shapes a senior Drupal architect chooses on a hand build, because they come from how we build production Drupal sites.

It verifies against what renders. Configuration being present is not proof, and markup existing in the DOM is not proof. The harness compares rendered pages against the source site, and it signs in to walk the editorial journeys your team will use in the delivered CMS. A migration that looks done in the config and wrong in the browser is not done, so the checking continues until the differences are boring. The series covers this in how we check a replatformed site really matches.

It delivers standard Drupal. The shipped site runs on zero custom modules. The theme is small, split and lint-clean. The configuration export contains what the site uses. Anyone who knows Drupal can maintain it from day one, and content created after the migration behaves exactly like content that came through it.

A person stays in the loop where judgement matters. An architect reviews every call the run hands to a person. The automation does the transcription; the judgement calls stay human. That is the honest division of labour, and it is why the result holds up to review.

We proved it on ourselves first: we moved our own site from Webflow to Drupal with the harness before pointing it at anything else.

What this changes about the decision

The design question disappears from the project. Keeping the design fixed removes an entire round of stakeholder review, and the visual layer arrives as components read from the site you already approved.

The content model stops depending on who happened to be available. The harness applies the modelling rules consistently across every component and every page, at the standard the scarce architect would set, and the architect's time goes to review, where their judgement counts.

And the economics move accordingly. When the transcription work stops being hand work, a replatform stops being priced like a rebuild. If you want to know what that would mean for your own site, get in touch.

The rest of the series tells the story behind the harness: fourteen generations of getting this wrong then right, what the build taught us about working with AI, the day we moved our own site off Webflow, what your team actually gets afterwards, what makes the delivered site readable to LLMs, and how we check the result really matches.

---