Large site estates · Cost and consolidation
A few hundred websites,half the run cost.
Cutting what a large multi-brand estate costs to run is an inventory problem before it is a platform problem. We audit and rank every property by real traffic, decide what to retire or merge before anyone reopens the platform question, and keep the sites still waiting patched and accounted for.
A Drupal and platform architect reads your situation and replies in writing, usually inside 24 hours. No calendar to juggle.
How we sequence a large estate: inventory first, rationalization next, and the waiting sites held safe throughout.
What we keep finding
Six patterns show up in almost every estate this size.
None of them are design problems. They are the reasons an estate costs what it costs, and the reasons a consolidation either holds or stalls.
Nobody owns the site list
Every geography stood up its own properties, every acquisition arrived with its own stack. The inventory exists in fragments, and none of them agree.
Duplicate builds of the same brand
The same brand exists three times in three regions, each with its own hosting line, its own subscriptions and its own vendor hours.
Stacks nobody on staff can patch
TYPO3, custom PHP, .NET, Shopify and Django sitting next to Drupal. When a CVE lands, there is no one whose job it is.
Catalog sites with no SLA behind them
Retail and channel partners depend on product properties that were never treated as production systems.
A vendor reporting tickets, not risk
Monthly reports count closed issues. They never say which properties are exposed, which are end of life, or what should be retired.
End of life arriving mid-program
Consolidation runs for a year or more. Platform versions do not wait for the phasing plan to be approved.
You cannot phase a consolidation you have not inventoried, and you cannot cost one you cannot list.
Structure
Inventory first, platform second
A consolidation plan that starts with the platform is a guess. The plans that hold start with an inventory: every property, its owner, its stack, its version, its traffic and who depends on it.
Traffic is the honest prioritization signal, not feature inventories. Rank the estate by real demand from your own consent or analytics data, and the phasing plan mostly writes itself: what moves first, what merges, what quietly goes away.
- One inventory of record, with an owner named per property
- Ranked by measured traffic, not by what each site claims to do
- Stack, version and end-of-life exposure recorded per site
Delivery risk
The risk is not the sites that move. It is the ones that wait.
In a multi-year consolidation, most properties spend most of the program waiting their turn. That waiting estate is the exposure: mixed stacks, unpatched releases, versions approaching end of life, and credentials nobody has audited since the last acquisition.
Migration schedules slip. Security schedules do not. Someone has to keep every property patched, monitored and accounted for while the estate shrinks around it, and report risk rather than ticket counts.
- Patch and release discipline across every stack still standing
- Monitoring, TLS and access reviewed per property, not per platform
- Monthly risk reporting a security team can actually act on
Cost structure
Half the cost is in the site list
Run cost rarely halves at the platform bill. It halves at the properties nobody defends once they are written down: duplicate regional builds, campaign sites that ended three years ago, catalog properties that belong inside a parent site.
Each one carries hosting, subscriptions, patching and vendor hours. Rationalization is the cheapest work in the program, and it is the work most consolidation plans skip because it needs an argument rather than an engineer.
- Retire, merge or migrate decided per property with evidence
- Support surface collapsed alongside the hosting footprint
- Savings modeled before the platform decision is reopened
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
Where consolidation showsA small governed template set that regional and brand teams can compose without engineering help. Consistent patterns across the estate, local personality only where it earns its place.
Data
StructuralOne content model across the estate. Product, catalog and location data treated as data rather than as pages, so it can be reused across brands instead of copied per site.
Activation
Governance firstRoles, moderation, scheduling and audit trail defined with the teams who publish. Directory-driven access and single sign-on sequenced as their own phase, not bolted onto a migration.
Optimization
Continuous, per batchProperties move in batches, each with its own mapping, QA gate, redirect plan and completion record. Cost, publishing time and support load measured per batch, so the argument gets stronger as it goes.
Credentials
Not new to Drupal. Not new to estates in the hundreds.
Teams who take their platform seriously
Proof · Estates we consolidated
Many owners, one governed platform, a smaller bill.
American Medical Association
Ten properties onto one governed Drupal platform
Campaign and resource sites scattered across platforms, taxonomy drift and accessibility debt. Audited across every property, migrated on deterministic pipelines, rebuilt on a reusable component model. Lighthouse moved from 24 to 98.
Retail estate, 90+ brands
One platform for a portfolio nobody could inventory
Brand and regional properties spread across stacks and owners. Consolidated onto a governed platform with shared components, so brand teams publish inside guardrails instead of commissioning builds.
IRONMAN
Hundreds of event sites off one governed codebase
A multi-brand estate with immovable race-day deadlines. Reusable components, structured content and webhook integrations, so local event teams ship their own sites without engineering on the critical path.
How the work is sequenced
Audit, then rationalize, then hold the line.
Estate audit and inventory of record
Every property catalogued: owner, stack, version, traffic, dependencies and exposure. Ranked by measured demand so the phasing conversation has data under it.
Weeks 1 to 5 · Evidence
Rationalization and phasing plan
Retire, merge or migrate decided per property, with the cost of each option written down. The platform decision comes after this, not before it.
Weeks 4 to 8 · Decision
Hold the line while the estate shrinks
Everything still standing stays patched, monitored and accounted for, batch by batch, with risk reported monthly rather than ticket counts.
Continuous · Gated per batch
Our thinking on estates this size
Written from estates we already moved.
How we sequence a fleet, where governance breaks, and what we audit before a single site migrates.
Open a brief
Tell us what the estate looks like today.
An architect reads it, not an SDR. You get a written response, usually inside 24 hours, with how we would audit the estate, where the cost and security exposure sits, and what we would leave alone for now. 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