Multisite Drupal · Locally managed estates
Hundreds of sites, one platform,local teams still in control.
Consolidating a large, locally managed site estate onto Drupal is a governance problem before it is a design problem. We standardize the template set first, ship the governance model on day one, and prove launch throughput on a small batch before the full rollout commits.
A Drupal architect reads your situation and replies in writing, usually inside 24 hours. No calendar to juggle.
How we sequence a consolidation: template set first, governance on day one, launch throughput proven on a small batch.
What we keep finding
Six patterns show up in almost every large, locally managed estate.
None of them are design problems. They are the reasons a platform replacement either holds for a decade or drifts apart within a year.
A template per site, by accident
Every batch of launches inherited whoever built them. Two sites that should be identical behave nothing alike.
Publishing that needs a ticket
Local teams have the content and the context, but not a way to ship it without technical help.
Shared content copied, never reused
The same menu, policy or brand block lives in hundreds of places, so it is never current in all of them.
Governance decided per team
No consistent roles, review states or audit trail. Who can publish what depends on who set the site up.
Thousands of components to move
Migration scope is counted in pages, then discovered in components. That is where estimates break.
Autonomy versus consolidation, unresolved
Local teams fear losing control. Left unanswered, that fear stalls the rollout long after the platform is ready.
The platform decision is usually the easy part. The hard part is whether several hundred local teams can work inside it on Monday morning.
Structure
Standardize the template set before anything moves
Several hundred sites do not need several hundred designs. They need a small template set, agreed and sized before a single page is migrated: a light local template, a mid-weight template with bookings and forms, and a heavier one carrying portals, logins and integrations.
One content model and one Drupal backend sit underneath, with decoupled front ends per template. Everything downstream inherits that decision: the component library, the permissions model, the migration mapping, the QA gates.
- Template sizing derived from sites in your estate that already work
- One content model, shared content reused rather than copied
- Component library governed centrally, composed locally
Delivery risk
The migration is not the risk. Divergence after go-live is.
Consolidation programs rarely fail during the build. They fail two release cycles after go-live, when hundreds of local teams publish the way they always have and the single platform quietly becomes many platforms again.
So roles, content moderation, scheduling and an audit trail ship on day one, modeled on how local teams actually work rather than on an org chart. Autonomy is designed in deliberately: what a local editor may change, what is inherited, and what is locked.
- Role-based access matched to real local workflows
- Review states, scheduling and rollback, not free-for-all publishing
- Every change attributable through a complete audit trail
Launch throughput
A new site should take days, not a project
Once the template set is real and components are governed, launching a site stops being engineering work. On our last consolidation of this shape, an approved design became a working site in under two days, composed by the team that owns the content.
This is the operational metric to hold an integrator to, because it is the one your teams feel every week after go-live. It also runs off the critical path, so it can be proven early on a small batch instead of promised at the end.
- Visual authoring your non-technical teams can use unaided
- Approved components only, so speed does not cost consistency
- Proven on a small batch before the full rollout commits
How we frame the work
Experience, Data, Activation, Optimization. Run as a loop, not a ladder.
We move the operational metrics inside each layer. Which of those matter to the business stays your hypothesis, not our claim.
Experience
The core of the workA sized template set drawn from your own estate, decoupled front ends per template, and visual authoring local teams can use without engineering help. Consistent patterns across every site, with local personality where it earns its place.
Data
StructuralOne content model across the estate. Shared content modeled as shared, site-specific content kept local, and structured operational data such as menus, hours and locations treated as data rather than as pages.
Activation
Governance firstRoles, moderation states, scheduling and audit trail defined with the teams who publish. Directory-driven access and single sign-on sequenced as their own phase rather than bolted onto the migration.
Optimization
Continuous, per batchSites migrate in batches, each with its own mapping, QA gate, redirect plan and completion record. Launch throughput, publishing time and support tickets are measured per batch, so the rollout gets faster with evidence behind it.
Credentials
Not new to Drupal. Not new to multisite at scale.
Teams who take their platform seriously
Proof · Estates we consolidated
Many local owners, one governed platform, content teams still shipping.
American Medical Association
Ten fragmented properties onto one governed Drupal platform
Campaign and resource sites scattered across platforms, taxonomy drift, accessibility debt and sensitive content. Audited across every property, migrated on deterministic pipelines, rebuilt on a reusable component model with real editorial workflows.
Fortune 200 group, named on request
Self-service multisite for 400+ operating companies
400+ operating companies, 90 countries, 110,000 employees. Local markets waited on engineering for every launch. We built portable, reusable configuration packages so markets ship their own sites inside a governed platform.
University of East London
Sitecore to Drupal, with the search experience rebuilt
Performance failures and no personalization layer. We migrated the estate, built advanced course search and a unified content hub, lifted applicant conversion 2.3x, and left the in-house team owning the design system.
How a consolidation is sequenced
Foundation, then a proven pilot, then pace.
Template set and content model
We size the template set against sites already working in your estate, then settle one content model and the governance map with the teams who publish. Nothing migrates until this is agreed.
Weeks 1 to 4 · Foundation
Pilot batch, proven end to end
A small batch migrates, launches and gets measured: publishing time, launch effort, support tickets. The rollout plan is rebuilt on that evidence rather than on the original estimate.
Weeks 5 to 8 · Evidence
Rolling migration at pace
Batches ship continuously, each with its own mapping, QA gate, redirect plan and completion record you keep. Local teams are onboarded batch by batch, not all at once.
Continuous · Gated per batch
Our thinking on consolidation
Written from estates we already moved.
Read how we sequence a fleet, where governance breaks, and what we automate before a single site migrates.
Open a brief
Tell us the estate you are trying to consolidate.
A Drupal architect reads it, not an SDR. You get a written response, usually inside 24 hours, with how we would sequence the consolidation, where the governance risk sits, and what we would leave alone. If we are not the right team, we will say so and point you to one we trust.
- Written assessment, no calendar bookings
- We will tell you what is not worth doing yet
- No sales sequences, unsubscribe anytime