Website consolidation · Governance and architecture
Choose the consolidation patternbefore you choose the product.
Hundreds of sites rarely fit one architecture. We group the estate by governance, isolation, load, release cadence and content model, settle the database and isolation call on evidence, write it down as a decision record, then prove it on representative sites before the estate commits.
An architect reads your situation and replies in writing, usually inside 24 hours. Read the framework below first, then book a call if it is useful.
How we sequence a consolidation: decision logic first, governance on day one, the architecture proved on representative sites.
What we keep finding
Six patterns show up in almost every large consolidation program.
None of them are design problems. They are the reasons a consolidation either holds for a decade or drifts apart within a year.
One pattern applied to every site
An estate of several hundred sites rarely fits a single architecture. Applied uniformly, one pattern under-serves the heaviest sites and over-serves the lightest.
Product chosen before the logic
The platform is selected, then the governance and isolation questions are answered inside constraints nobody chose deliberately.
No written record of the decision
The wiring gets inherited, the reasoning does not. The next team cannot tell which trade-offs were accepted and which were missed.
Governance decided per team
Roles, review states and approvals differ site by site, so who can publish what depends on who set the site up.
Failure boundary widened quietly
Shared infrastructure lowers platform overhead and, unless it is bounded on purpose, turns one incident into an estate-wide one.
Local autonomy left unresolved
Local teams fear losing publishing control. Unanswered, that fear stalls the rollout long after the platform is ready.
The platform choice is usually the easy part. The hard part is whether several hundred local teams can work inside it on Monday morning.
Decision logic
Classify the estate before you choose a product
A few hundred sites do not need a few hundred architectures. They need a small number of classes, agreed before anything moves: grouped by ownership, content model, release cadence, load profile, integration surface and isolation requirement.
That classification is what makes the rest of the program decidable. Template set, permissions model, migration mapping and QA gates all inherit it, and every later exception is measured against it instead of negotiated ad hoc.
- Site classes drawn from your own estate, not a reference architecture
- Conditions written for shared infrastructure and for justified exceptions
- Products selected after the decision logic is settled, never before
Architecture decision
One database or many is a governance call, not a default
A single shared instance and database is simpler to run and lets shared content be genuinely shared. It also means one failure scope, one restore scope and one release calendar for every site in the estate.
Separate databases, whether through Drupal multisite on a shared codebase or Acquia Multi-Experience Operations, buy real isolation per site or per group. The cost is provisioning work, cross-site reporting that has to be aggregated deliberately, and a higher operational floor.
We make the call on evidence: how independent the local release calendars really are, what regional or regulatory isolation you owe, how uneven the load is, and how much content is genuinely shared. Then we write it down as a decision record, so the next team inherits the reasoning and not just the wiring.
- Shared instance, grouped databases, or per-site isolation, chosen against your release reality
- Failure boundary, restore scope and release calendars named before the build
- A written architecture decision record you keep, including the options we rejected
Governance model
Consolidation programs come apart after go-live, not during the build
Two release cycles after launch, local teams publish the way they always did, exceptions accumulate, and the single platform quietly becomes many platforms again. That is the failure mode worth designing against.
So roles, moderation states, 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 deliberately: what a local editor may change, what is inherited from the center, and what is locked.
- Role-based access matched to real local workflows
- Review states, scheduling and rollback instead of open publishing
- Every change attributable through a complete audit trail
Editorial experience
Remove the technical dependency from everyday publishing
The reason local teams hold on to their own sites is rarely the design. It is that they can change something without filing a ticket. Consolidation only holds if the new platform gives them more of that, not less.
So the editorial layer is the product, not the finish. Approved components, in-browser composition, no theme code in the daily path. We work on Drupal Canvas and Experience Builder in the open, with a standing team on bugs, features and cleanup, because reducing the developer dependency inside Drupal itself is the same problem your marketing teams have.
- In-browser page composition from a governed component set
- No theme or template code needed for routine editorial work
- Standing Axelerant team contributing to Drupal Canvas and Experience Builder
Representative proof
Make the architecture prove itself before the estate commits
Pick representative sites from each class and test the pattern end to end: deployment, rollback, editorial workflow, isolation behavior and load handling. Record where the shared pattern holds and where an exception is justified.
The same batch tests adoption. Most local teams have never used the target platform, so onboarding is role-shaped sessions, a written playbook for the ten tasks each role actually does, and office hours through the first batches. Adoption is measured per batch, not declared at handover.
- Isolation, load, deployment, rollback and workflow tested on real sites
- Rollout plan rebuilt on pilot evidence rather than the original estimate
- Role-shaped onboarding for editors, approvers and site owners
Platform depth
We fix this upstream, so you are not carrying a fork
Our Open Source Contribution Committee funds work back into Drupal, and we are a Drupal Association Certified Platinum Partner and a top-20 contributor worldwide. Practically, the authoring and governance gaps we hit on your estate get fixed in core and contrib where we can, not patched into a private branch you own forever.
On the hosting side, a 12-year Acquia partnership covers Site Factory and Multi-Experience Operations, which is usually where the isolation question gets settled in practice.
- Fixes pushed upstream instead of into a private fork
- Platinum Drupal Association partner, top-20 contributor worldwide
- Long-standing Acquia partnership, including Site Factory and MEO work
Where we have done this work
Six situations we are called into, and the estates behind them.
Locally managed site estates
Hundreds of sites run by regional, campus or operating-company teams with low technical depth, each one drifting from the last batch that built it.
Legacy or unfit CMS replacement
Proprietary or end-of-life platforms where routine edits need a developer and the migration surface is counted in components, not pages.
Multi-brand and multi-region publishing
Shared brand and policy content that must stay current everywhere, alongside genuinely local content that has to stay local.
Uneven load and isolation duties
A handful of high-traffic or regulated properties sitting in the same estate as long-tail sites that barely move.
Governance across many owners
One approvals model, one audit trail and one set of roles across teams that never shared a workflow before.
Publishing throughput after go-live
New sites and campaign pages produced by the teams that own the content, in days, without engineering on the critical path.
Sectors we run large estates in
- Food services and hospitality operations
- Higher education and research
- Healthcare and professional membership
- Nonprofit, NGO and multilateral
- Manufacturing and consumer brands
- Sports, events and media
How the work is delivered
One accountable team, four lenses, named people who stay.
Founded 2005, remote-first since 2012, 150+ people, 21 years of signed work. People decide and own the work, while AI shoulders analysis and evidence organization.
One accountable team
Four lensesStrategy, Engineering, Design and Marketing examine the same decision together, so the architecture call, the editorial model and the rollout plan are not written by three disconnected groups.
Embedded seniors
Named peopleThe architect who writes the decision record stays through the migration batches. Remote-first since 2012, working inside your calendar and your tooling.
Evidence over opinion
Per batchEach batch carries its own mapping, QA gate, redirect plan and completion record you keep. Deployment effort, exception volume and time to publish are measured as it goes.
Outputs we own
Hypothesis you ownWe commit to the agreed outputs and movement in the operational metrics behind every release. Which business results those ladder into stays your hypothesis, not our claim.
Platform credentials
Not new to Drupal. Not new to multisite at scale.
Teams who take their platform seriously
Case studies · Estates we consolidated
Many local owners, one governed platform, content teams still shipping.
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.
How a consolidation is sequenced
Decision logic, then proof, then pace.
Estate classification and decision record
We group the estate into site classes, settle the governance model with the teams who publish, and write the architecture decision record: databases, isolation, exceptions and the trade-offs we rejected.
Weeks 1 to 4 · Decision logic
Representative sites, proven end to end
One site per class migrates and launches. Isolation, load, deployment, rollback, editorial workflow and adoption are tested and measured, and the rollout plan is rebuilt on that evidence.
Weeks 5 to 8 · Evidence
Rolling migration, gated per batch
Batches ship continuously, each with its own mapping, QA gate, redirect plan and completion record. 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 classify 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.
An architect reads it, not an SDR. You get a written response, usually inside 24 hours, with how we would classify the estate, where the isolation and 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 first, a call only if you want one
- We will tell you what is not worth doing yet
- No sales sequences, unsubscribe anytime
Would rather talk it through? Book a candid call with an architect. Thirty minutes, no deck.