MSM Multi Site Manager — Managing Content Across Sites and Languages

Content Objective

In this chapter, you'll understand:

• What MSM is and the core problem it solves
• How Blueprints and Live Copies create a parent-child content relationship
• How rollout configurations control what syncs and what doesn't
• Localization strategies for multi-language and multi-region sites
• Common MSM pitfalls in production and how to avoid them
• How architects think about MSM for global enterprise implementations

Where We Are

By now you have a solid content architecture foundation — you understand content types, fragment models, and how content is structured. There's one more challenge that enterprise projects always face: what happens when you have the same content across multiple sites?

A global company doesn't have one website. They have a US site, a UK site, a German site, a French site. A retail brand might have a flagship site and regional franchise sites. A university might have a main site plus department microsites.

Without a strategy, you end up duplicating content everywhere and losing control fast. MSM is AEM's answer to that problem.

Part 1: The Core Problem MSM Solves

Imagine a global brand with 20 regional websites. They release a new product. Every regional site needs:

• A product page
• Updated navigation
• Updated homepage banner
• Updated footer disclaimer

Without MSM, someone manually creates or copies this content to 20 sites. It takes days. Regional teams inevitably customize things. Six months later, you have 20 versions of the product page that have all drifted apart.

MSM solves this with three concepts:

1. Blueprint — The master source of content
2. Live Copy — A site that inherits content from the Blueprint
3. Rollout — The process that pushes Blueprint changes to Live Copies

Changes flow from Blueprint → Live Copies. One update, many sites.

Part 2: Blueprints

A Blueprint is the master template for a site or section of content. It's the authoritative source — the version that all Live Copies inherit from.

/content/
└── mycompany/
    └── blueprint/          ← Blueprint root
        ├── en/             ← Master language
        │   ├── home
        │   ├── products/
        │   └── about
        └── brand-assets/

You create content in the Blueprint exactly as you would on any AEM site. Authors edit pages, add components, configure templates. Nothing special — it's just a regular AEM site that's been designated as a Blueprint.

What Makes a Good Blueprint

The Blueprint should contain the content that is shared across all sites. Content that's site-specific should live directly in the Live Copy, not in the Blueprint.

Good candidates for Blueprint content:

• Global navigation structure
• Core product pages
• Brand templates and styles
• Legal disclaimers
• Shared components and configurations

Bad candidates:

• Region-specific pricing
• Local campaign content
• Country-specific legal text
• Translated content (handled separately)

Part 3: Live Copies

A Live Copy is a site that inherits content from a Blueprint. When you create a Live Copy, AEM copies the Blueprint content structure and maintains a relationship between each page and its Blueprint source.

/content/
└── mycompany/
    ├── blueprint/en/            ← Blueprint
    ├── us/en/                   ← Live Copy (US)
    ├── uk/en/                   ← Live Copy (UK)
    ├── de/                      ← Live Copy (Germany, localized)
    └── fr/                      ← Live Copy (France, localized)

The Live Copy Relationship

Each page in a Live Copy has a hidden cq:LiveRelationship mixin on its node, pointing back to the Blueprint source.

/content/mycompany/us/en/products/laptop-pro
└── jcr:content
    └── cq:LiveSyncConfig
        ├── cq:master = /content/mycompany/blueprint/en/products/laptop-pro
        └── cq:isDeep = true

This relationship is what allows rollouts to work — AEM follows the relationship to know which Blueprint page maps to which Live Copy page.

Inheritance and Suspension

By default, Live Copy pages inherit from the Blueprint. Any rollout of Blueprint changes flows down to the Live Copy.

But regional teams sometimes need to customize a page. AEM lets you suspend or cancel inheritance on individual pages or individual component properties.

Live Copy Page → Suspend Inheritance
                 └── This page no longer receives Blueprint updates
                 └── Regional team can now customize freely

Or more precisely, you can suspend a single property:

Page title inherited from Blueprint ← can suspend this one field
Page body inherited from Blueprint  ← keep this synced

This granularity is what makes MSM powerful. You can say: "Keep the product description from the Blueprint, but let regional teams customize the price and CTA."

Part 4: Rollout Configurations

A rollout configuration defines what happens when you roll out from Blueprint to Live Copies. It's the rulebook for sync.

Default Rollout Actions

The standard rollout configuration (called "Standard Rollout") includes these actions:

Custom Rollout Triggers

You can control when rollouts happen:

Manual rollout — An author triggers it explicitly from the Blueprint or Live Copy On Blueprint activation — When a Blueprint page is published, Live Copies auto-update On modification — Any change to the Blueprint page triggers a rollout (use carefully — can flood replication)

For most enterprise projects, manual rollout with optional on-activation is the right balance. Fully automatic rollouts on every modification are too aggressive.

Rollout Scope

You can roll out at different levels:

• Single page — Just this one page and its components
• Page and subpages — This page and everything below it
• Entire site — The full Blueprint tree

For daily content operations, single-page rollout is most common. Full-site rollout is used for initial setup or major global campaigns.

Part 5: Localization Strategy

MSM handles content synchronization. Localization (translating content into different languages) is a separate concern, but they work together.

Translation Workflow

AEM has a built-in Translation Integration Framework (TIF) that connects to translation services (Adobe Translation, Google Translate, third-party LSPs like SDL).

The typical flow:

Blueprint (English)
    ↓ MSM Rollout
Live Copy (German) — receives English content structure
    ↓ Translation Job
Live Copy (German) — translated German content fills in
    ↓ Reviewer approves
Live Copy (German) — published with German content

Language Master Pattern

A common enterprise pattern is the Language Master:

/content/mycompany/
├── language-masters/
│   ├── en/          ← Language master (not live site)
│   ├── de/          ← German translations
│   └── fr/          ← French translations
└── sites/
    ├── us/en/       ← Live Copy from language-masters/en
    ├── uk/en/       ← Live Copy from language-masters/en
    ├── de/de/       ← Live Copy from language-masters/de
    └── fr/fr/       ← Live Copy from language-masters/fr

Language masters aren't live sites — they're translation repositories. Once translation is approved, the content rolls out from the language master to regional Live Copies.

This separation keeps translation work clean and prevents half-translated content from accidentally appearing on live sites.

What Not to Translate Through MSM

Not everything in a Live Copy should come from translation. Some content should be created directly in the regional site:

• Local contact information
• Region-specific promotions and pricing
• Local legal requirements
• Country-specific news and events
• Regional social media links

These should have suspended inheritance or be created as local pages (not Live Copy pages).

Part 6: Real-World Architectures

Case Study 1: Global Consumer Brand (15 Countries)

Challenge: A global apparel brand has 15 regional sites. Global product launches need consistent messaging. Regional teams customize pricing, promotions, and local campaigns.

Architecture:

/content/brand/
├── blueprint/
│   └── en/ (global English source)
│       ├── products/
│       ├── collections/
│       └── brand-story/
└── sites/
    ├── us/en/   (US, English)
    ├── uk/en/   (UK, English — same language, different region)
    ├── de/de/   (Germany, German)
    ├── fr/fr/   (France, French)
    └── [11 more...]

Rollout rules:

• Product pages: auto-rollout on Blueprint activation (global products need immediate sync)
• Collection pages: manual rollout (regional teams review before it goes live)
• Promotions: local content only, no rollout (each region has different campaigns)

Result: Product launches are consistent globally within minutes. Regional teams retain autonomy over campaigns. Legal updates to product descriptions roll out in one action instead of 15 manual edits.

Case Study 2: University Multi-Site (Main + Departments)

Challenge: A university has a main site and 40 department microsites. Navigation, header, footer, and brand elements must be consistent. Each department controls its own content.

Architecture:

/content/university/
├── blueprint/
│   └── en/
│       ├── header-fragments/
│       ├── footer-fragments/
│       └── shared-pages/
│           ├── about-university
│           └── admissions
└── sites/
    ├── main/
    ├── computer-science/
    ├── business-school/
    └── [38 more departments...]

Rollout rules:

• Header/footer components: full inheritance, auto-rollout (brand consistency non-negotiable)
• About/admissions pages: inherited, can be locally customized
• Department-specific pages: local only (no Blueprint equivalent)

Result: Brand refresh takes one change to the blueprint header — 40 sites update within 24 hours. Department teams never need to worry about keeping navigation in sync.

Case Study 3: Financial Services (Multi-Brand)

Challenge: A financial group has three brands (retail banking, investment, insurance). All three share compliance components, legal disclaimers, and shared service pages. Each brand has its own look, products, and marketing.

Architecture:

/content/fingroup/
├── global-blueprint/
│   └── shared/ (compliance, legal, service pages)
├── retail-bank/
│   ├── blueprint/   (retail bank source)
│   └── sites/
│       ├── us-retail/
│       └── uk-retail/
├── investment/
│   ├── blueprint/
│   └── sites/
│       ├── us-investment/
│       └── uk-investment/
└── insurance/
    └── [similar structure]

Key architectural decision: Nested blueprints. The global blueprint handles compliance. Brand blueprints handle brand-specific content. Regional Live Copies inherit from both levels.

Result: Compliance team updates one page — all three brands, six regional sites update. Brand teams update their blueprints — only their regional sites update. No cross-brand contamination.

Part 7: Production Troubleshooting

Problem: Rollout Not Updating Live Copy

Symptom: You triggered a rollout on the Blueprint, but Live Copy pages still show old content.

Root Cause 1: Inheritance was suspended on the Live Copy page.

Check:

Open the Live Copy page → Page Properties → Live Copy tab
Look for: "Inheritance suspended" or red indicator

If suspended, resume inheritance and re-roll out.

Root Cause 2: The rollout configuration doesn't include contentUpdate action.

Check:

Tools → Sites → Rollout Configurations
Check what actions are included in your configuration

Root Cause 3: The page was created locally in the Live Copy, not via rollout. It has no cq:LiveRelationship.

Fix: The page needs to be created via rollout, not manually, for MSM to manage it.

Problem: Live Copy Has Content That Shouldn't Be There

Symptom: Blueprint content appears in a regional site that should have local content.

Root Cause: Local team didn't suspend inheritance before editing. Blueprint rollout overwrote their changes.

Fix:

1. Suspend inheritance on the affected page or components
2. Re-apply the local customizations
3. Train the regional team on when to suspend inheritance before editing

This is one of the most common MSM support tickets. The answer is always the same: inherit by default, suspend explicitly when you want to go local.

Problem: Translation Content Being Overwritten

Symptom: Translated German content is being replaced with English from the Blueprint after rollouts.

Root Cause: Rollout configuration doesn't exclude translated content from sync.

Fix: Configure your rollout to skip translated properties. The standard configuration has a languageCopy action that handles this, but it needs to be set up correctly for your structure.

Alternatively, use a translation status flag on each page. Rollout actions check the flag — if the page is "translated and approved", the contentUpdate action skips translated text fields.

Problem: MSM Creates Duplicate Pages During Rollout

Symptom: After a rollout, there are duplicate pages in the Live Copy.

Root Cause: The same page was created both via rollout (from Blueprint) AND manually in the Live Copy. Now there are two pages with similar paths.

Fix: This usually happens during initial setup. Audit the Live Copy for manually created pages that have Blueprint equivalents. Delete the duplicates and ensure the Live Copy version has the proper cq:LiveRelationship.

Part 8: Architect Perspective

MSM Is Not Free

MSM saves content maintenance time, but it has operational overhead. Authors need to understand inheritance. Editors need to know when to suspend and when to let inheritance run. Support teams need to understand rollout failures.

Before recommending MSM, ask:

• How many sites? (2-3 sites may not justify MSM complexity)
• How much shared content? (If sites are 90% different, MSM may not help)
• Do regional teams have AEM training? (Inheritance confusion is the #1 support issue)

When MSM Is Worth It

• 5+ sites with significant shared content
• Frequent global updates that need consistent rollout
• Content governance requirements (brand, legal, compliance)
• Regional teams that need autonomy within global guardrails

When to Skip MSM

• Completely independent sites with different brands (just use separate site trees)
• Temporary microsites (MSM overhead isn't worth it for 3-month campaign sites)
• Sites with very different structures (MSM works best when structures are similar)

MSM + Content Fragments: The Hybrid Approach

Some teams use a hybrid: MSM for pages (navigation, templates, shared pages), and Content Fragments with fragment references for content (shared disclaimers, global product descriptions).

MSM handles: page structure, templates, navigation
Content Fragments handle: shared text, global disclaimers, product data

This gives you structural consistency from MSM and content reuse from fragments, without the complexity of trying to manage detailed content through MSM inheritance rules.

Summary

MSM is one of AEM's most powerful features for enterprise multi-site management, and one of the most misused.

The fundamentals to remember:

1. Blueprint = source of truth — Content flows from Blueprint to Live Copies, never the reverse.

2. Inherit by default, customize explicitly — Live Copies should inherit. Suspend inheritance only when you have a specific regional need.

3. Rollout configs are your control panel — They define what syncs, what doesn't, and when. Design them intentionally.

4. Language masters separate translation from sync — Don't try to do translation and MSM sync in the same workflow. Separate concerns.

5. MSM has a learning curve — Budget for training regional authors. Inheritance confusion causes more support tickets than configuration bugs.

6. Hybrid MSM + Fragments is often the best answer — Pages from MSM, shared content from fragments.

When MSM is set up correctly, a global brand manager updates a product launch page in the Blueprint and watches it propagate to 20 regional sites within minutes. That's the promise. Getting there requires the architecture decisions in this chapter.

What's Next

Module 3 is complete. You now understand the full content architecture layer of AEM:

• Chapter 13: Choosing the right content type (Pages, Assets, Fragments)
• Chapter 14: Content Fragment architecture and API delivery
• Chapter 15: Experience Fragments for reusable designed blocks
• Chapter 16: Content modeling that scales
• Chapter 17: MSM for multi-site, multi-language management

Module 4 — AEM Backend Architecture is next. We'll move into the Java layer: OSGi Services, Service Users, Schedulers, Event Handling, and Workflow Architecture.

• Chapter 18: OSGi Services — The service layer that powers AEM's backend