X to Drupal: QED42 Migrates 646 Pages From Webflow to Drupal 11

Early iterations of QED42's AI-assisted website reconstruction produced pages that looked correct to visitors but left editors facing raw JSON instead of usable content fields. That failure helped reshape X to Drupal, the company's AI-assisted framework for migrating existing websites to Drupal 11 without necessarily redesigning them. The system has since been used to move QED42's own 646-page website from Webflow to Drupal. Speaking to The DropTimes through detailed written responses, Souvik Pal, Senior Backend Engineer at QED42, described the engineering decisions, unexpected failures and limitations that emerged during the framework's development.

X to Drupal is designed to separate two responsibilities frequently combined in website migration projects: replacing an existing content management system and redesigning the website itself. Souvik said organisations often postpone platform changes because a migration becomes a larger programme involving new designs, content reconstruction, stakeholder approvals and additional development costs. QED42's approach is to retain an existing design when it remains appropriate, while rebuilding the content structures, components and editorial functionality underneath. The company offers the framework as an accelerator within its engineering engagements, not as an independently operated one-click migration tool.

The framework originated from a different experiment. QED42 initially developed a prompt-based site builder using its design system, but the team identified a more practical application in reconstructing websites that organisations were already operating. The company's own website, then running on Webflow, became the testing ground. QED42 has handled replatforming projects since 2011, and Souvik said the new framework shifts much of the repetitive reconstruction work into an automated process while retaining engineers' responsibility for architecture, review and launch.

A public website address provides the starting point. X to Drupal examines the pages visitors can access, identifying repeated layouts, content patterns, media, navigation, forms and visual properties such as typography, spacing and responsive breakpoints. It groups pages into templates and attempts to infer the structures needed to reproduce them in Drupal. Because the process begins with rendered pages rather than depending exclusively on the source CMS, QED42 says it can be applied to Webflow, WordPress, Sitecore and custom-built websites. However, the company has presented its own Webflow migration as the principal production example, and functionality hidden from public view requires additional investigation.

The migration process consists of five stages: reading the source website, rebuilding it in Drupal, configuring supporting functionality, verifying the result, and generating documentation. Repeated sections become reusable components, while content and media are transferred into a structured Drupal implementation. The harness also configures navigation, forms, listings, redirects, metadata, and AI-related functionality. Validation gates sit between stages. A phase can proceed automatically only when its required checks have run successfully; missing evidence or failed checks require human intervention.

The resulting content model is central to the approach. Articles, case studies and events receive dedicated Drupal content types with typed fields, while one-off pages can use a flexible page type. Reusable page sections are developed as Single Directory Components and can be managed through Paragraphs or placed directly in Drupal Canvas, depending on the architecture selected for the project. Listings become Views, categories and filters become taxonomies, forms use Webform, and shared elements such as headers and navigation are handled through blocks. An architect reviews the proposed content model before implementation continues.

That review can prevent subtle mistakes. Souvik described category chips on QED42's homepage that initially appeared to be ordinary content but were actually part of a filtering interface. Treating them as static content would have reproduced the appearance while losing the underlying behaviour. Other decisions, such as whether a collection of cards should be manually curated or generated through a View, cannot necessarily be inferred from the public page. The harness proposes structures, but editors' intentions and business requirements still have to be established.

QED42's own migration involved 646 public pages organised around 17 page templates and seven forms. The company reports transferring 569 article bodies and 2,007 images to Drupal 11, while a separate verification process examined 670 advertised addresses. Souvik said the harness completed its automated reconstruction work in approximately four days. That figure does not represent the full project duration: QED42's published delivery information gives a three-to-five-week kickoff-to-launch window for a website of comparable complexity, including review and production preparation. The company reports that its resulting website retains the established design and runs with standard Drupal functionality rather than custom modules carrying its core implementation.

Reaching that result took 14 generations of the framework between May and July 2026. One of the most significant changes followed an early implementation that passed visual checks but stored every component as a single JSON payload in a long-text field. Drupal rendered the pages correctly, yet editors opening those pages encountered structured data rather than familiar fields for headings, images, links, and repeatable content. The team subsequently rebuilt the generated content model around typed fields and native Drupal editing widgets.

The problem exposed a weakness in using visual fidelity as the principal measure of migration success. A website can appear unchanged while its underlying structures make editing, maintenance or future content creation unnecessarily difficult. Souvik said the team's acceptance criteria therefore expanded beyond rendered pages to include the editing interface itself. Every component needed meaningful fields, and the generated structures had to support new content as well as material migrated from the original site.

Other problems were less immediately visible. At one development stage, QED42's Drupal media library contained just two Media entities representing 1,359 images in use across the website. The images appeared on the public pages, but the backend was not managing them as individual assets. The team changed the framework to create proper Media entities and added checks using authenticated editorial accounts, rather than relying only on anonymous visitor sessions. A separate audit of 670 addresses uncovered 14 category listings without working routes on the migrated website. Those routes were built before launch.

Earlier generations also missed a newsletter modal and reproduced a complex navigation menu as a flat list. The team incorporated checks for those problems into subsequent versions. Webflow-specific markup inside migrated content required a dedicated cleaning process so that the Drupal installation could use its own text formats and filtering mechanisms. Souvik also described a recurring problem with corrections applied directly to generated output: those changes disappeared during the next clean execution. The team consequently required fixes to be implemented within the generator and reproduced consistently from a fresh run.

Some verification findings proved misleading themselves. When the team rechecked four previously diagnosed defects, only one had been located correctly; the other three had been attributed to the wrong places. QED42 subsequently tightened its verification requirements and prohibited important checks from being bypassed. The framework now treats an unavailable result as unavailable rather than interpreting the absence of evidence as a successful check.

Incorrect content associations remain a particularly serious concern. A migrated page may be technically valid while displaying an image in the wrong section, placing a summary in an inappropriate field or combining two different content concepts into one component structure. Those errors can survive basic validation, especially when the resulting page still renders successfully.

To address such errors, the harness records where each component field obtains its source value and traces headings, paragraphs and images to their original pages and sections. Content appearing on the wrong page, being duplicated or crossing between pages is treated as a blocking defect. Groups of pages assigned to the same template are also checked for variations, while architects review cases where similar-looking elements represent different concepts. Souvik gave the example of a case-study card and a partner logo: their appearance might overlap, but treating them as the same editorial structure could produce an unsuitable content model.

Verification combines visual comparison with content and address accounting. QED42 says the harness checks rendered pages against their source equivalents across desktop, tablet and mobile widths, including declared responsive breakpoints. It compares component styles, tracks missing or misassigned content, confirms that referenced media can render and checks whether original URLs remain accessible or redirect appropriately. The company does not publish a single averaged visual parity score, arguing that high similarity across simple pages could conceal important defects on complex ones. Human review remains necessary for animation, visual nuances, accessibility and behaviour that screenshots cannot establish. A final comparison also accounts for changes made to the original site while the migration is underway.

The reliance on public pages creates another practical boundary. The harness can reproduce visible form fields, but it cannot determine where submissions should be sent, which employees should receive notifications or how a CRM should process the resulting information without additional input. Authentication, restricted content, editorial approval rules, internal integrations and custom business logic must be documented with the client. Single-page applications, personalised content, A/B testing, interactive calculators, externally powered search and complex animations can introduce further work. Third-party embeds may be carried over, but functionality controlled by the external provider remains outside the reconstructed Drupal site. Access to an existing codebase, database export, API, or CMS can provide information unavailable through the public URL, although Souvik said those alternative routes are planned individually, and the public-URL approach is currently the most extensively developed.

Beyond migration, QED42 has incorporated Drupal's AI-related functionality into the delivered system. The setup includes the client's own AI provider credentials, metadata and structured data, sitemaps, redirects, an llms.txt file, Markdown representations of pages and read-only JSON:API access. These provide structured and machine-readable ways to access website content, although their presence does not establish improved search rankings or inclusion in AI-generated answers. A runbook generated from the completed site documents its components, content architecture and editing procedures. The framework also configures standard editorial capabilities such as revisions, scheduling, media management and role-based permissions, alongside performance and security settings.

Another capability allows AI assistants to request Drupal content changes through the Model Context Protocol (MCP). Souvik said assistants connect as Drupal users with assigned permissions, rather than obtaining unrestricted access to the CMS. Operations are checked against Drupal's entity-access rules, and generated content enters as an unpublished draft for editorial review. Revisions remain available, and organisations requiring more formal approval procedures can incorporate Drupal's Content Moderation workflows. The assistant also uses the generated runbook and captured brand context to understand the site's structure before making changes.

Testing exposed a potential weakness in that integration. When QED42 connected an MCP client using a low-privilege account, the available interface initially exposed 72 tools, including some that did not consistently enforce Drupal entity-access checks. The team selected a tool layer that checked access for individual operations, disabled tools outside an explicit allowlist and reduced the available interface to 14 tools. Souvik said low-privilege testing remains part of the process.

QED42 also aims to keep the generated Drupal architecture reproducible and maintainable after handover. The content model, theme and configuration are built around Drupal core and contributed functionality, with a Drupal Recipe used to reconstruct the implementation on a fresh Drupal 11 installation. Souvik said the company's production website ultimately required no custom modules to carry its generated content architecture. Small custom modules introduced after launch, including functionality related to sitemap dates and MCP tools, were subsequently replaced with contributed modules and configuration. Client-specific development remains possible where existing contributed functionality cannot meet a requirement, but such code is kept separate from the framework-generated foundation and developed with conventional engineering standards and tests.

Retaining the existing design is nevertheless not appropriate for every website. Souvik advised reconsidering that approach when information architecture no longer reflects audience needs, navigation has become difficult to use, accessibility barriers are embedded in the design, or excessive component variations have accumulated. Poor mobile journeys, abandoned forms, and planned rebranding can also justify a redesign. The framework can support a new design once the intended components and content mappings are established, or allow organisations to migrate first and update individual components later. Markup improvements such as landmarks, skip links and required alternative text cannot resolve every accessibility problem, and full conformance still requires appropriate review. QED42 also identifies deeper AI authoring across existing content libraries and a more comprehensive automated SEO audit as capabilities still under development.

The company's production migration provides a documented example of AI-assisted reconstruction, but it does not establish how consistently the framework will perform across different client websites or source technologies. Its four-day harness execution is not a substitute for the architectural decisions, quality assurance, and launch preparation that surround a migration. Souvik's account makes a distinction especially relevant to Drupal teams evaluating similar approaches: visual similarity is necessary for a faithful redesign-free migration, but the content model, editorial usability, business functionality and verifiable completeness determine whether the resulting CMS can be maintained after handover. Further information and QED42's technical documentation are available through the X to Drupal website and its technical article series.