01
Set at the core
Update once, launch everywhere
A shared component, template, price book, or policy lives at the core. You edit it once and the change applies across all your digital properties.
MANAGE YOUR PROPERTIES
One core. Every property. Shared or local, by your rules.
1
instance
unlimited sites, stores, brands, and locations under one core
Save a Life I Clark Rubber I YMCA I Frontier Touring
One core. Every property branches from it.
Set your structure once - templates, components, catalogs, navigation, and rules - and every property inherits from it. A new region, brand, or location branches off that core, taking what it shares and overriding only what is local. One instance models the whole hierarchy.
- One core every property inherits from
- Branch by region, brand, location, or tenant
- The platform mirrors your org, not a workaround
how inheritance works
Set it once. Override only what's different.
The mechanism every multi-site platform is built on - without the rollout configs or the engineering team to run them.
02
Inherits everywhere
Every property that shares it updates
The change flows down to every site that inherits it - one edit, not seventy. You see which properties it touches before it ships.
03
Override locally
Make one property differ, without forking the rest
When a site, brand, or region needs to differ, override it in place. The local version takes over for that property only; everything else keeps inheriting.
04
Detach when needed
Or let one stand fully on its own
When a property needs full independence, detach it from the core - then re-link it whenever you want it inheriting again. Shared to independent is a spectrum you control.
One structure. Every shape your business takes.
01
Multi-region & multi-language
One brand, every market it sells in - the same site in English, Spanish, and whatever languages you need. Translate once from a shared structure; regional pricing, currency, and compliance are handled per market, not rebuilt site by site.
02
Multi-brand portfolios
A portfolio of brands under one roof. Each keeps its own storefront, identity, and prices, selling from a shared catalog - while the back office, components, and governance stay shared at the core.
03
Franchise & dealer networks
One brand across many locations. A shared storefront where inventory, fulfilment, and pricing route by location, and each franchise or dealer runs its own patch. Corporate sets the structure; local owns the edges.
04
Membership & chapter networks
One organisation, many chapters and programs. A shared identity that branches into program sites and event microsites, each chapter owning its own content - while every visitor sees one organisation.
The rollout you used to configure. Now you describe it.
The one-to-many rollout an enterprise DXP makes you configure, you describe in plain language - and because the agent reads your structure first, it knows shared from local and which properties a change should touch. Describing it is safe, not reckless. It runs on a live MCP server - 80+ tools, 400+ APIs - so a lean team can drive the whole portfolio from any AI chat.
- One prompt, live across every property
- Shared changes ship; local overrides stay untouched
- Approval and audit on every change
- A lean team runs the whole portfolio
Enterprise-grade AI, governed by the structure you already built.
You don't configure new safety for the AI. The structure, permissions, and approvals you already built are what govern it.
Your permissions, respected
The agent acts inside the exact role and scope each person already has. It can't touch a property, brand, or field that person couldn't touch in the admin. Your access model governs the AI.
It knows shared from local
The agent reads your inheritance model before it acts - changing what's shared and leaving every local override intact. A portfolio-wide change never overwrites a property's own version.
See every property before it ships
A per-property diff shows exactly which sites a change touches and what each will look like, before anyone approves. No blind rollouts across the estate.
Approval on your rules
Nothing reaches a live property without the approval your workflow requires - one approver for low-risk, two for pricing or legal, set per group and per role.
Full audit, one-click rollback
Every prompt, plan, and change is logged with who, when, and which property. If something's wrong, one click reverts it across every property it touched.
Scoped, never let loose
Agents run within the ceilings and scopes you set. Anything out of scope routes to a human. The boundaries are enforced by the platform, not left to trust.
Multi-site architecture, three ways
Why operators outgrow brand-by-brand and bolt-on multisite.
Real multi-site architecture has only ever come two ways: an enterprise DXP with the full inheritance model but a developer team to run it, or a stack of separate sites and plugins that drifts. Here is how the three compare on what actually matters when you run a portfolio.
| Capability |
Enterprise DXP
Adobe, Sitecore - full model, developer-run |
DIY & bolt-on multisite
Separate stores, multisite plugins, cloned sites |
Core dna
Full architecture, run by a lean team |
|---|---|---|---|
|
The inheritance model
Shared core, local override, one-to-many rollout |
Full, but configured Blueprints, live copies, rollouts - the complete model, set up and maintained by developers. | Mostly absent Plugins approximate it; cloned sites don't have it at all. Shared changes are manual. | Built in Core, inheritance, and per-property override are native. No rollout configs to engineer. |
|
A change across every property
Updating one thing everywhere it lives |
Configured rollout A developer sets up and triggers a one-to-many rollout for each change. | Manual, site by site Someone edits each property by hand and hopes nothing was missed. | One edit, or one prompt Edit the core once, or describe the change in plain language. You see every property it touches first. |
|
Adding a property
What it takes to launch the next site |
Dev project A new site is an engineering and template project on the existing build. | Clone and diverge Copy an existing site; from then on it drifts on its own. | Configure a branch Start the new property from a governed template; it inherits the core from day one. Hours, not a project. |
|
Brand consistency
Keeping every property on-brand as you grow |
Enforced if configured Strong, once inheritance and governance are correctly set up and maintained. | Drifts With no shared core, properties diverge until no two match. | Held by inheritance Shared elements stay shared by default; local change is a deliberate, visible override. |
|
Localisation
Every language and market, on one structure |
Language copies (dev) Capable, via language copies and translation projects configured by the team. | Separate sites Each market tends to become its own site to maintain by hand. | Structural Language and regional versions keep one structure; translate a shared component once, it carries everywhere. |
|
Who controls what
Governance across the hierarchy |
Granular, complex Deep permissioning, but it takes expertise to model and administer. | Scattered Access lives in separate logins; oversight of who can touch what is thin. | Mapped to the hierarchy Corporate owns the core, local owns the edges. Every change versioned, with who and when. |
|
Moving your existing sites on
Getting a live estate onto the platform |
Re-implementation Typically a full rebuild on the new platform, measured in many months. | Site by site Each property migrates on its own; the estate moves piecemeal. | Consolidation path One migration consolidates the portfolio onto one instance. See how implementation works below. |
|
Who runs it, day to day
The team the model actually requires |
Developers + IT A standing engineering team to operate rollouts, templates, and releases. | Whoever's left Manual work spread across whoever can log into each site. | Marketing & ops A lean team runs the whole portfolio from one platform, without dev tickets. |
The inheritance model
Shared core, local override, one-to-many rollout
Enterprise DXPFull, but configured
Blueprints, live copies, rollouts - the complete model, set up and maintained by developers.
DIY & bolt-on multisiteMostly absent
Plugins approximate it; cloned sites don't have it at all. Shared changes are manual.
Core dnaBuilt in
Core, inheritance, and per-property override are native. No rollout configs to engineer.
A change across every property
Updating one thing everywhere it lives
Enterprise DXPConfigured rollout
A developer sets up and triggers a one-to-many rollout for each change.
DIY & bolt-on multisiteManual, site by site
Someone edits each property by hand and hopes nothing was missed.
Core dnaOne edit, or one prompt
Edit the core once, or describe the change in plain language. You see every property it touches first.
Adding a property
What it takes to launch the next site
Enterprise DXPDev project
A new site is an engineering and template project on the existing build.
DIY & bolt-on multisiteClone and diverge
Copy an existing site; from then on it drifts on its own.
Core dnaConfigure a branch
Start the new property from a governed template; it inherits the core from day one. Hours, not a project.
Brand consistency
Keeping every property on-brand as you grow
Enterprise DXPEnforced if configured
Strong, once inheritance and governance are correctly set up and maintained.
DIY & bolt-on multisiteDrifts
With no shared core, properties diverge until no two match.
Core dnaHeld by inheritance
Shared elements stay shared by default; local change is a deliberate, visible override.
Localisation
Every language and market, on one structure
Enterprise DXPLanguage copies (dev)
Capable, via language copies and translation projects configured by the team.
DIY & bolt-on multisiteSeparate sites
Each market tends to become its own site to maintain by hand.
Core dnaStructural
Language and regional versions keep one structure; translate a shared component once, it carries everywhere.
Who controls what
Governance across the hierarchy
Enterprise DXPGranular, complex
Deep permissioning, but it takes expertise to model and administer.
DIY & bolt-on multisiteScattered
Access lives in separate logins; oversight of who can touch what is thin.
Core dnaMapped to the hierarchy
Corporate owns the core, local owns the edges. Every change versioned, with who and when.
Moving your existing sites on
Getting a live estate onto the platform
Enterprise DXPRe-implementation
Typically a full rebuild on the new platform, measured in many months.
DIY & bolt-on multisiteSite by site
Each property migrates on its own; the estate moves piecemeal.
Core dnaConsolidation path
One migration consolidates the portfolio onto one instance. See how implementation works below.
Who runs it, day to day
The team the model actually requires
Enterprise DXPDevelopers + IT
A standing engineering team to operate rollouts, templates, and releases.
DIY & bolt-on multisiteWhoever's left
Manual work spread across whoever can log into each site.
Core dnaMarketing & ops
A lean team runs the whole portfolio from one platform, without dev tickets.
Yes, because the structure governs it. The agent acts inside the exact permissions each person already has, reads your inheritance model so it knows shared from local, and shows a per-property diff before anything ships. Every change runs through your approval rules, is logged with who/when/which property, and can be rolled back in one click. You don't configure new safety for the AI, the structure, permissions, and approvals you already built are what contain it.
That's the typical path: rather than re-implementing every property, a migration consolidates the estate onto one instance, mapping shared structure once and configuring each property's local differences. Most teams move in stages, prove the model on one property, then scale across the rest at the pace that fits the team instead of a single high-risk big-bang rebuild.
A new property starts from a governed template and inherits the core from day one: domain, brand identity, catalog scope, pricing, and integrations configured rather than rebuilt. It's a configuration step measured in hours to days, not a new platform contract or a months-long engineering project, so the cost of adding the tenth property looks nothing like building the second one from scratch.
Yes. Each property can have its own domain, storefront identity, and pricing rules while drawing from one shared catalog. Products live once as a single source of truth; each storefront shows the slice it sells, at its own prices and promotions. So one brand can sit premium and another value, on the same SKU, without duplicating data or maintaining separate systems.
One platform, three relationships. Multi-site is the umbrella term: many websites or storefronts running on one shared core. Multi-store usually means one company running several branded storefronts from a single admin, often sharing a catalog and customer records. Multi-tenant means independent operators: franchisees, dealers, or separate businesses, each with isolated data and their own logins on shared infrastructure. Core dna supports all three on one instance: you decide what's shared at the core and what each property controls locally.
GET STARTED
Book a 20 min demo