Coverage

What a replatform includes

A replatform covers two kinds of work: what the harness builds on every run, and what the delivery team does around that run. Work that depends on your own site, such as hosting, analytics set-up or integrations, is scoped separately for each site.

In the topic groups, each line without a chip is something the harness does on every run, not something one delivered site happened to get. Where a line depends on a condition, or is optional, that is written under it. Get in touch about your own site.

How to read this list

Built by every replatform
The harness does this on every run. Where a condition applies, or a check is optional, it is written under the line.
Done by the delivery team, part of the replatformDelivery team
The hands-on work around the run: scoping and discovery, QA and fixes, accessibility, forms, go-live and hypercare, and project management.
Scoped separately for each site
It depends on your site, so we scope it with you, site by site.

Part of the replatform

What a replatform covers

In the groups below, every line without a chip is built by the harness on every replatform. The lines marked Delivery team are the hands-on work around the run, and they are part of the replatform too. Work scoped separately sits in its own panel at the end.

Content and structure

  • The content of every public page: headings, body, links and imagesTraced from the source page to the rendered page, and any exception is named.
  • A missing or wrong page, menu item or link counts as a defect, not a cosmetic issue
  • Every page address found, from the sitemap and a crawl of the navigation
  • Existing page addresses kept exactly as they are
  • The redirects the source site already hadOnly redirects the source site actually serves.
  • Author bylines turned into Drupal usersWhere a page shows a single author.
  • Publish dates carried across
  • Not-found and access-denied pagesWhen the source site has them.
  • The source site's robots.txt Disallow rulesPages the source robots.txt blocks are not migrated.
  • QA and fixes: content checks on a sample of migrated pages, and the fixes they surfaceDelivery teamOn top of the harness's own final QA.

Site building

  • A content model built from the templates your site already uses
  • Pages built from components with typed fields
  • Listings built as native Drupal Views
  • Listing filters, only where the source site has a filter control
  • Taxonomies built from the categories the source site uses
  • Menus checked item by item against the source navigation
  • A media library that arrives holding the site's own images
  • Each form on the source site rebuilt as a Drupal WebformSending submissions on to an outside system is scoped separately.
  • Limits on every file upload field in a form
  • Forms: end-to-end tests on every form in scopeDelivery teamAgainst your real endpoints, not stubs.

Design parity

  • A Drupal theme generated from the source design, built from single-directory components
  • Design tokens, and the site's own fonts served from the site
  • Every template compared with the source at desktop, tablet and phone widthsMeasured internally; no parity score is published.
  • Every responsive breakpoint the source site declares
  • Hover and focus states
  • Favicons and touch icons
  • Animation, scroll effects and video backgroundsReproduced closest to the resting state; motion is the hardest part to match.
  • Sites from builders that generate class names, such as Wix and some Framer sitesSupported, with more review of the finished components.
  • QA and fixes: design-parity checks on each template family, and the fixes they surfaceDelivery teamOn top of the harness's own final QA.

SEO and search

  • Meta tags with a title pattern and a canonical address on every page
  • Each page's own meta description, kept word for word
  • Open Graph share tags, including the share image and title
  • Schema.org structured data: Organization, WebSite, WebPage, Article or BlogPosting, and Service
  • Address patterns for pages editors add later, matched to the site's own templates
  • An XML sitemap covering every content typeIts host name is set once the production address is known.
  • A check that every address on the old site has a page on the new one
  • SEO fields in the sidebar of the edit form
  • The Drupal CMS AI recipe for SEOApplied once a working AI provider key is in place.

Analytics and tags

The harness adds no analytics or tag scripts of its own. Setting those up is scoped separately.

Accessibility

  • Alternative text required on image fieldsNot required where the image is decorative on the source site.
  • A main landmark and a skip-link target in every page template
  • The source site's ARIA roles carried through into the components
  • An automated accessibility sweepAn optional audit that reports every finding.
  • Accessibility: keyboard and screen-reader checks, with fixesDelivery teamA keyboard and screen-reader pass over each distinct pattern.

Performance, CDN and hosting

  • Built on Drupal 11 and Drupal CMS
  • An object cacheUsed when the host provides Redis; otherwise the database cache.
  • WebP versions of resized images
  • An image toolkit that can process AVIF and other source image formatsSwitched on only once the server proves it can process them.
  • Scheduled jobs split so each one runs on its own timetable
  • A performance budget check for load time, layout shift and page weightAn optional report, page by page.
  • A portable deliverable: configuration, content, theme and a database dump
  • Installable from scratch as a Drupal 11 RecipeFor a fresh install. Public files, such as images, fonts and downloads, travel beside the Recipe, not inside it, and the database dump is the full restore path.
  • A database dump that is proven to restore

Security

  • An enforcing content security policy, built from the site's own embeds
  • HTTPS-only strict transport security (HSTS)Carried over where the source site already sends it, with the same policy.
  • A cross-site request check, a referrer policy and same-origin framing
  • Spam protection on every formNo CAPTCHA is added.
  • Secrets read from the environment, never stored in configuration or the database dump
  • A least-privilege editor role, with access granted menu by menu
  • JSON:API kept read-only, with the user accounts resource switched off
  • Third-party files served from the site itself, rather than loosening the security policy
  • Theme templates with no unescaped output

AI and agent readiness

  • Drupal's AI module suite, with two providers installedSet up against your own provider key; its settings apply once that key works.
  • An AI assistant button in every rich-text editor
  • Alternative text generated for images where it is missing
  • Usage, response time and error logging for every AI call
  • An llms.txt map of the site
  • A markdown twin of every content page, at the page's address with .md added
  • Read-only JSON for each content item
  • robots.txt rules that name AI crawlers one by one
  • A Model Context Protocol connection: a change described in plain language arrives in Drupal as a draftNothing publishes itself. An editor reviews the draft and publishes it.
  • Drupal's ECA automation moduleInstalled, with a first automation set up.

Editorial

  • Editor permissions derived from this site's own content model
  • Bulk publish and unpublishFor content under an editorial approval workflow, which is scoped separately.
  • Scheduled publishing on every content type
  • A rendered preview of each component on the edit form
  • Help text on editor fieldsWritten as fields are generated, and not yet complete on every field.
  • A test that creates, edits and saves each content typeRun in the build environment, never on the live site.
  • A runbook for your content team: the content model in plain English, with every component shown populatedWhere each part of a page comes from, and how to manage taxonomies, menus and listings.
  • Editor guidance through the generated runbook and the site's Model Context Protocol connection, in place of a training week

Verification and delivery

  • Quality checks throughout the run, so the result is right before it is handed over
  • People review and sign off the result before it goes live
  • A signed-in crawl of the admin screens
  • Every page checked to still carry the source page's sections
  • A re-check against the live source siteOptional, run on request.
  • A QA report on the finished siteRead-only: it reports and changes nothing.
  • No custom modules and no build tooling left in the delivered site
  • Scoping & discoveryDelivery teamAgreeing what parity means, what is out of scope, access and sign-offs.
  • Go-live and hypercare: we run the go-live, and anything that surfaces in production is ours to fixDelivery teamEnvironments, DNS cutover and a rollback plan, then a fixed on-call window of two to four weeks.

Scoped separately

What depends on your own site

These depend on your site, so each one is scoped separately, for that site.

  • Hosting and setting up the hostHosting fees are paid to the host.
  • A CDN and a web application firewall on the hostIncluding clearing the CDN cache when content changes.
  • Google Analytics 4 set-up
  • Google Tag Manager and the tags inside it
  • Google Search Console set-up
  • CRM and other third-party integrationsFor example single sign-on or marketing tools.
  • Sending form submissions to an outside system, such as a CRM
  • FAQ and breadcrumb structured data, and breadcrumb navigationAdded as part of a custom scope.
  • Custom functionality and business logicFor example portals, calculators or bespoke workflows.
  • An editorial approval workflow, with draft, review and published stagesAdded as part of a custom scope.
  • EcommerceCatalogue, checkout and payments.
  • Multilingual content and translation
  • Content behind a loginThe crawl reads public pages only.
  • Single-page app sourcesHeavily client-rendered sites and infinite scroll.
  • Design changes or a redesign
  • Copywriting, content decisions and a new information architecture
  • A WCAG conformance statement or audit
  • A privacy review
  • A security review or penetration test
  • Support after the hypercare window
  • Usage on your own AI provider accountBilled to you by the provider.
  • Sites over 100 template families or 10,000 pagesScoped by hand, template family by template family.