Yes, you can run several brand websites from one Xperience by Kentico instance. Each brand becomes a website channel, shared content lives in the Content Hub, and each brand's code sits in its own Razor Class Library. It usually costs less to run than separate installations, but one problem can touch every brand. Here is how it works, what drives the cost, and when separate instances still win.

Quick answer

One instance, many website channels: one per brand.
Shared content goes in the Content Hub; brand code goes in Razor Class Libraries.
Great for moderate traffic and shared content. Risky if one brand is huge or compliance demands full isolation.
Planning one? Talk to our Kentico development team.

Is a Multi-Brand Kentico Setup Right for You?

One instance is a good fit when...	Think twice when...
Brands share products, legal copy or media	One brand gets far more traffic than the rest
You want one editorial system and one deployment	Rules require fully separate databases per brand
You launch new brands or campaign sites often	Brands run on very different tech stacks
Your team already works in .NET	Each brand needs its own release calendar

Not sure Kentico is the right platform at all? Start with how to choose the right DXP, or read what Kentico is first.

Why One CMS Per Brand Gets Painful

You pay for everything several times. Each installation needs its own server, database, license and deployment pipeline. With three or more brands, the bill adds up fast.
Content drifts apart. Brand A updates a product description, someone pastes it into Brand B, and six months later nobody knows which one is right.
Brands stop looking related. Headers, footers and navigation get rebuilt separately, so designers end up maintaining parallel systems.
Customer data is scattered. Contacts, subscriptions and tracking live in different databases, which makes cross-brand campaigns hard.
New brands launch slowly. Provisioning a fresh environment can turn a two-week job into a two-month one.

How Multi-Brand Works in Xperience by Kentico

Six ideas make it work. If Kentico is new to you, our guide to Xperience by Kentico covers the basics.

1. Website channels

A website channel is a self-contained site inside one Xperience instance, with its own domain, content tree, URL structure and language settings. Make one per brand. Kentico's multi-site documentation describes this approach.

2. The Content Hub

The Content Hub sits outside any single channel. Put shared articles, product specs and media there, and several brand sites can use the same item. Update it once and every site that uses it shows the change. That ends the copy-and-paste problem.

3. Razor Class Libraries for code isolation

Create one Razor Class Library (RCL) per brand, such as BrandA.Web and BrandB.Web, plus a Shared.Web library for common layouts and components. Brand code stays in its own project, so a change for Brand A can't quietly break Brand B. Each RCL needs [assembly: CMS.AssemblyDiscoverable] so Xperience can find its classes, as the official docs explain.

4. Content type namespaces

When two brands both want a "ProductPage" type, you get a clash. Prefix each type with a namespace: BrandA.ProductPage, BrandB.ProductPage, and Shared.Article for shared ones.

5. Governance and permissions

Roles can be scoped per channel, so a Brand A editor only sees Brand A, while a global content manager sees the Content Hub. This keeps brands in control of their own content without bottlenecks. It is one reason enterprise Xperience by Kentico development projects with several teams lean on channels.

6. AIRA for cross-brand efficiency

AIRA is Kentico's AI assistant in the admin. It can help draft, translate and adapt shared content for each brand's tone. It speeds up the work, but editors still make the final call.

Figure 1: Multi-brand architecture in Xperience by Kentico. Blue boxes represent website channels, teal is the Content Hub, purple boxes are Razor Class Libraries, and gray is the shared database layer.

How Teams Did It on Kentico 12 and 13

Many teams on Kentico 12 and 13 ended up with one installation per brand. If that is where you are today, this will look familiar:

Separate servers and databases. A new virtual machine, IIS setup, SQL database and license key for every brand.
Copy-paste content. Editors exported pages from one admin and imported them into another. Some teams built sync scripts with the Staging module, but those were fragile.
Parallel codebases. Navigation, footers and form handlers were duplicated, and every fix had to be applied several times.
Independent deployments. Safe for each brand, but shared improvements took weeks to reach everyone.

How to Build It on Xperience by Kentico

Create a website channel per brand. In Channel Management, set the domain, languages and URL rules. Three brands take minutes to configure, not weeks.
Fill the Content Hub. Add shared product descriptions, bios, disclaimers and media. Editors work in one place.
Set up the Razor Class Libraries. One per brand plus a shared one, all in the same Visual Studio solution and referenced from the main web project.
Scope permissions and deploy once. Set channel roles and workflows, then ship the whole solution through one pipeline. If you want the bigger picture, see the benefits of Kentico.

Want a team that has done this before? See our Xperience by Kentico development services or hire dedicated Kentico developers.

Figure 2: Traditional approach (coral, left) versus current Xperience by Kentico approach (teal, right). Each path shows four steps from setup to deployment.

A Common Trap: Content Type Name Collisions

Content type code names must be unique across the whole instance. If both brand teams create ProductPage, the second registration fails. Agree on a convention before anyone models content:

BrandA.ProductPage for Brand A
BrandB.ProductPage for Brand B
Shared.Article for types used by every channel

The namespace is just part of the code name, so Kentico won't enforce it. Write it down and check it in code review. Teams that skip this often find out after content exists, when renaming gets painful.

Kentico Multisite vs Multiple Instances

Factor	Single instance (multiple channels)	One instance per brand
Infrastructure cost	Lower: one server, one database	Higher: repeated per brand
Content sharing	Built in through the Content Hub	Export/import or custom API sync
Code isolation	RCLs inside one solution	Fully separate codebases
Deployment risk	Shared: one bad release can hit every brand	Isolated per brand
Performance isolation	Shared resources; one brand's spike can affect others	Fully isolated
Data isolation / compliance	Shared database	Full separation
Time to add a brand	Hours to days (new channel, new RCL)	Days to weeks
Governance	Channel-scoped roles and workflows	Instance-level roles only
Maintenance	One system to patch	N systems to patch

Moving Existing Brand Sites Into One Instance

If your brands already run on Kentico 12 or 13, or on another CMS, consolidating is a migration project, not a version bump. A sensible order:

Audit each site. Content types, custom modules, integrations, traffic and URLs.
Design the shared model. Decide what goes in the Content Hub and agree the namespace convention.
Migrate in phases. Start with the lowest-risk brand to learn on.
Protect your SEO. Map every old URL to a new one and test the redirects before launch.

Our team handles this through Kentico migration services and Xperience by Kentico upgrade services. Still on Kentico 13? Plan the move soon, because Kentico 13 support is ending [ADD: confirm date on Kentico's lifecycle page before publishing].

How Much Does a Multi-Brand Kentico Website Cost?

There is no honest one-size price, but these drive it:

Number of brands and how different their designs are.
How much is shared: layouts, components and Content Hub content.
Integrations such as CRM, ERP, payments and single sign-on.
Content migration volume and URL redirects.
Hosting and support choices.

The first brand carries the architecture work. Each extra brand usually costs less because you reuse the foundations. For ballpark figures, read Kentico development cost, then ask for a scoped estimate. Check licensing details with Kentico or your partner.

Planning a multi-brand build? Get a free architecture review: we'll look at your brands, content and traffic and tell you whether one instance fits. Book a free consultation or learn more about our Kentico development company.

What Works Well

The Content Hub ends duplicate content. For shared catalogs, legal pages and bios, the "which version is correct?" question goes away.

Channel-scoped permissions keep teams independent. Brand editors stay in their own space, and a global admin still sees everything.

RCLs keep the front end tidy. Without them, shared codebases fill up with if (brand == "A") logic. With them, each brand is its own project and shared layouts live in one place. The pattern scales to many brands.

From our projects: [ADD: one real DotStark multi-brand or consolidation example: number of brands, what was shared, one result with a number, and one thing we would do differently.]

The Honest Trade-offs

One failure can hit every brand. A database outage or a bad release affects all sites at once. Staged rollouts, blue-green deployments and canary testing reduce the risk but don't remove it.

Content type governance is a habit, not a feature. Nothing stops a new developer skipping the namespace, so you need documentation and code review.

Shared databases have a ceiling. If one brand gets 5 million daily visitors and another gets 50,000, the busy brand's load can slow everyone down. At that point, separate instances may be the better design.

Multi-brand grows into multi-channel. Xperience also supports email and headless channels, so the same Content Hub can feed a newsletter or a mobile app. Plenty of teams that start with three websites end up managing many more channels on the same content model.

Choosing a Kentico Development Partner

Multi-brand projects are architecture-heavy, so the partner matters. Look for:

Experience with Xperience by Kentico, not just older versions.
A clear approach to content modeling, namespaces and RCL structure.
Migration experience, including redirects and SEO protection.
Ongoing Kentico support services after launch.
Flexible engagement, from a full project team to dedicated Kentico developers.

For US-based teams, see our Kentico services for the USA.

The Bottom Line

With Xperience by Kentico, a multi-brand website is no longer about duplicating infrastructure. Each brand is a website channel, shared content lives in the Content Hub, code is isolated with Razor Class Libraries, and permissions are scoped per channel. You trade some deployment isolation for lower cost and simpler operations. For most organizations with moderate traffic and overlapping content, that is a good deal. If you need hard performance or compliance isolation, separate instances remain valid. Exploring Kentico for web development? That guide is a good next step.

FAQ

Can Xperience by Kentico run multiple brand websites from a single installation?

Yes. Xperience by Kentico supports multiple website channels in one application instance. Each channel has its own domain, content tree and page templates, while sharing one database, the Content Hub and the admin interface. For most organizations with several brands, this costs less to run and is easier to maintain than separate installations.

What is a website channel in Xperience by Kentico?

A website channel is an independent website managed inside the Xperience by Kentico administration. Each one has its own domain, content tree, URL structure and language settings. Several website channels can live in a single Xperience application, which is what makes multi-brand management possible without separate CMS installations.

How does the Content Hub help with multi-brand content sharing?

The Content Hub is a central repository for reusable content such as articles, product descriptions, media and structured data. Content created there exists independently of any website channel, so editors can reuse the same item across several brand websites, email channels or headless channels. This removes duplicate data entry and keeps shared information consistent.

When should I use separate Kentico instances instead of one multi-brand instance?

Choose separate instances when brands have very different traffic levels, when regulations require full data isolation, when brands use very different technology stacks, or when each brand needs its own release schedule. For moderate traffic and shared content, one instance with several website channels is usually cheaper and simpler.

What are Razor Class Libraries and why use them for multi-brand Kentico projects?

Razor Class Libraries (RCLs) are .NET library projects that hold Razor views, controllers and static assets. In a multi-brand build, each brand gets its own RCL, such as BrandA.Web and BrandB.Web, and a Shared.Web RCL holds common layouts and components. This keeps brand code separate, reduces merge conflicts and lets different teams work on different brands.

How much does a multi-brand Kentico website cost?

Cost depends on the number of brands, how much design and functionality is shared, integrations, content migration and hosting. The first brand carries the platform and architecture work, and each additional brand usually costs less because layouts, components and content models are reused. A scoped estimate from a Kentico development partner is the only reliable way to get a number.

Can I move my existing Kentico 13 brand websites into one Xperience by Kentico instance?

Yes, but it is a migration project rather than a simple upgrade. You audit each site's content types, custom code and integrations, design a shared content model and namespace convention, migrate content in phases, and map redirects so search rankings are protected.

How long does it take to build a multi-brand website on Kentico?

A small group of similar brands can take a few months, while larger portfolios with migration, integrations and custom design take longer. Reusing a shared design system and Content Hub content across brands shortens each additional brand.

Ready to consolidate your brand websites on Kentico? Contact DotStark for a free multi-brand architecture consultation.

Building a Multi-Brand Website on Kentico: Architecture, Cost and Trade-offs

Is a Multi-Brand Kentico Setup Right for You?

Why One CMS Per Brand Gets Painful