The multi-brand website decision: when to centralize and when to split

Every acquisition comes with websites, and somebody has to decide what happens next. Centralize everything into one CMS, or let each brand run its own site? That decision affects integration speed, governance, SEO continuity, technical debt, and operational risk. Here's the framework I use after 15 years of multi-brand web work.

Start with the operating model, not the CMS

The mistake is treating this like a platform decision first. It isn't. It's an operating model decision. Your site structure should reflect how the business actually runs: who owns marketing, who approves changes, what brands share, and how independent those brands really are.

If the organization behaves like one company, a centralized web model usually works. If it behaves like a portfolio, forcing everything into one system usually creates more friction than efficiency.

The four variables that decide it

I would make the call based on four questions:

1. Who owns the work? One central team, or separate brand teams with their own priorities?
2. How similar is the content model? Same products, same journeys, same conversion paths, or materially different structures?
3. How strict do permissions need to be? Is cross-brand visibility mildly annoying, or completely unacceptable?
4. How likely is future separation? Could a brand be sold, spun out, or restructured later?

If those answers point in the same direction, the decision is straightforward. If they conflict, default to the structure that preserves separation. It's much easier to centralize later than to unwind a badly centralized mess.

When centralizing makes sense

Centralize when the business is actually shared, not just when leadership wants standardization.

1. Ownership is centralized. One team runs strategy, publishing, and governance across brands.
2. The workflows are mostly identical. Similar content types, similar approval paths, similar lead flows.
3. The data model is materially the same. Same product logic, same RFQ structure, same taxonomy, same core templates.
4. Permissions are manageable inside one system. A mistake would be inconvenient, not a regulatory or competitive problem.
5. Efficiency matters more than local autonomy. Shared code, templates, integrations, and one update path are worth more than brand-level flexibility.
6. Content genuinely syndicates. If case studies, product families, resources, or campaign pages need to move across brands, centralization reduces duplicate work.

This works best when the brands are variations on one model: same core offer, same lead flow, same template system.

When splitting is the better move

Split when the business units are independent enough that shared infrastructure creates more problems than leverage.

1. Ownership is distributed. Different marketing leaders, different budgets, different reporting lines, different priorities.
2. The content model diverges. One brand sells configurable engineered systems, another sells straightforward catalog products. Forcing both into one schema usually gets ugly.
3. Permissions and isolation actually matter. Separate partner networks, channel conflict, compliance issues, or internal sensitivity around data and assets.
4. The brands may need to separate later. Spin-out, divestiture, or PE reshuffling all get cleaner when the web stack is already separable.
5. Operational risk is concentrated in the wrong place. Tightly coupled systems are great when you fix one bug and all 50 brands benefit. They are brutal when one bad deploy, one bad integration, or one infrastructure failure takes down all 50 at once.

Standalone doesn't mean starting from scratch. Shared starter themes, a component library, common integrations, and scripted deployments preserve most of the efficiency without forcing everything into one admin.

What a VP of Marketing should pressure-test

Before approving either direction, ask:

• Who is the real owner? Not who should own it politically. Who will actually be in the CMS every week?
• What breaks if Brand A sees Brand B's assets, drafts, or analytics?
• Are we standardizing because the customer journey is similar, or because we want procurement simplicity?
• If we acquire two more brands next year, does this architecture get easier or harder to govern?
• If one brand is sold in 18 months, how painful is extraction?

These questions usually get you to the answer faster than a tool comparison.

How to preserve flexibility during an acquisition

The first phase after an acquisition is usually messy. That's fine. The goal on day one is not perfect consolidation. The goal is to preserve options while protecting traffic, domains, and governance.

1. Get IT involved early. Marketing owns the website experience, but IT usually owns infrastructure, DNS, security, identity, and email. In PE-backed environments, there is often an existing integration playbook. Use it.
2. Secure the domains immediately. Acquire control of every relevant domain and subdomain, even the neglected ones. Old domains often still carry backlinks, rankings, and paid search value.
3. Do not kill SEO equity with lazy redirects. Sending an acquired site's entire URL structure to the homepage destroys value. Map important URLs to relevant destinations.
4. Use the transition period to learn the operating reality. Most acquired brands run semi-independently for a while. That is your window to determine whether convergence is real or just aspirational.
5. Set a decision date. Temporary architectures have a way of becoming permanent. Put a date on the calendar for the centralize-versus-split decision.

Technical decisions to make before choosing a platform

• One database or many. Shared databases reduce maintenance. Separate data stores make permissions cleaner and extraction easier.
• Permission boundaries. Can the platform cleanly enforce who edits, drafts, publishes, and administers each brand?
• Asset strategy. Decide whether images, documents, and product files live in a shared DAM, shared CDN structure, or per-brand storage.
• Redirect governance. Any consolidation plan should include explicit redirect mapping for valuable URLs, not homepage dumps.
• Domain ownership. Someone has to own renewals, SSL, DNS, and registrar access across the portfolio. This sounds basic until a domain expires.
• Exit readiness. If a brand has to leave the portfolio, can you extract its content, forms, analytics, and infrastructure without surgery?

What scale teaches you

I spent over a decade with a packaging machinery conglomerate that grew from 13 brands to 57. The biggest lesson was simple: architecture decisions fail when governance is fuzzy. If nobody documents how new brands get onboarded, who approves exceptions, and what gets shared versus isolated, the portfolio turns into an expensive collection of one-off decisions.

The second lesson is to resist feature creep. Brand A wants a calculator. Brand B wants a variation. Brand C wants one too. Fine at three brands. Unmanageable at ten. Impossible at 50. Multi-brand systems only stay healthy if someone evaluates features at the portfolio level, not just brand by brand.

The simplest rule of thumb

If the organization behaves like one company, centralize. If it behaves like a portfolio, split. If you're unsure, preserve separation until shared ownership, shared workflows, and shared data models are proven in practice.

There is no universal answer, only tradeoffs. But bad outcomes usually come from the same mistake: designing the web architecture around a desired future org chart instead of the business as it actually operates. Mirror reality first. Standardize second.