Upgrading to Extended Enterprise: Will I have to Reconfigure Everything?

The short answer to both questions: your existing platform and configuration stay intact when EE is activated. Nothing resets.

1. Root domain vs. becoming a client

You have two realistic paths here:

Option A — Your existing program stays on the root domain, the new program gets an EE subdomain. This is the simpler path by far. Your current users, branding, catalogs, SSO, and settings remain exactly as they are. The new program gets its own subdomain with independent look, branding, and SSO configuration.

Pros: zero disruption to your existing learners, no migration, your current URLs stay the same. Cons: some advanced settings are global across all domains — logout redirects, localization changes, certain gamification settings affect every domain. As one community member noted, "if you redirect the user to another page during the logout, this is for all the platforms." If the two programs need fundamentally different behavior at that level, you'll have friction.

Option B — Both programs become EE subdomains, root stays as an admin shell. Cleaner separation — full branding/SSO/notification independence for both. Better architecture if you expect more programs down the road.

Cons: you'd need to migrate your existing learners to the new subdomain and update SSO metadata, bookmarks, all communications. That's a significant lift. For most situations where one program is clearly the established one and the other is new, Option A makes more sense.

2. Your existing configuration carries over

Your current branding, pages, menus, and advanced settings stay as the default on the root domain. The new subdomain starts with a blank branding slate — you configure it independently. One thing worth knowing: if you enable custom CSS on the subdomain, root CSS does not inherit — you'll need to configure it separately.

A few things worth planning for:

• All users technically can access the root domain — as one admin in the community put it, "every user is associated with the root branch." You manage this by only distributing subdomain URLs to the new audience and keeping catalog assignments scoped to specific branches/groups. It's about controlling what they see, not where they can go.
• Configure your custom domain before SSO. SSO metadata is tied to the URL. Change the domain later, and you redo SSO from scratch.
• Watch the domain level limit — Docebo supports a maximum of 3 domain levels. Community members have reported issues when trying to use 4 levels (like parent.subdomain.org/subfolder).
• Avoid public catalogs on the root level once EE is active. They can override subdomain home pages and create conflicts with subdomain-specific content.
• Get the new subdomain looking right before connecting users to it. Set up branding, pages, and menus first, then bind branches. Nobody sees a half-finished experience that way.

The overall time investment shouldn't be huge — the bulk of the work is designing the new subdomain's branding, pages, and user provisioning flow. Your existing program should be minimally affected.

Official docs:

• Managing the Extended Enterprise App
• Configuring Secondary Domains

Community threads from others who've been through this:

• EE Implementation Discussion
• Keeping Users in Their Domain
• New Platform vs. EE Subdomain
• EE Setup Discussion

Let me know if you want to dig into any of these areas more specifically.