Surge Migrate

Guide · updated

AEM migration for manufacturers with multi-brand, multi-language sites

Manufacturers often run many brands and dozens of country sites on one AEM 6.5 installation, held together by Multi Site Manager (MSM) live copies and translation projects. That structure is where most of the migration risk sits. The features still exist in AEM as a Cloud Service; what changes is how brands map to Cloud Manager programs and pipelines, and how much of your inheritance model survives the move intact. This guide covers what Adobe documents and what to check.

MSM and translation are separate tools

Adobe is explicit that "MSM does not translate the content": it creates the structure and rolls content out. Translation is done with language copies and the translation integration framework. Adobe describes two ways to build language masters, its recommended layer of un-activated source pages: language copies, which is what the built-in translation framework uses, and MSM live copies, which it describes as an alternative for larger, more complex sites.

  • Language roots are pages named with an ISO language code (for example de or de_CH, or de-CH). Each language copy needs a correctly configured language root.
  • Language roots can be grouped one level down, for example by region, but only one level: a root two levels down is not detected as a language copy.
  • Adobe's translation best practice is a language-based structure of no more than three levels, at the top of the site.
  • AEM connects to Microsoft Translator by default; other translation vendors' connectors are on Adobe Exchange. Without a connector, translation content can be exported and re-imported as XML.

Clean up the inheritance model before you move it

Ten years of rollouts leave live copies with cancelled inheritance, custom rollout configurations and chains of live copies of live copies. Adobe's MSM best practices apply on Cloud Service too:

  • "Customize as much as necessary, but as little as possible": every custom rollout configuration is something to re-test after the move.
  • "Un-governed, chained inheritances can significantly increase the complexity of a MSM structure." Flatten chains where you can.
  • Rollouts triggered on every modification (onModify) "may have a negative impact on authoring performance"; use them only where the benefit is clear.
  • Cancelled inheritance at page or component level is how local and translated content is protected from the next rollout. Inventory where it is used and why.

Experience fragments take part in MSM too: Adobe notes that MSM works with experience fragments because they are part of a page, so include them in the inheritance inventory.

Moving the content

Content moves with the Content Transfer Tool. Adobe's documentation does not say how it treats MSM relationships or translation projects, so treat their survival as something to verify, not assume. Points Adobe does document:

  • Versions are optional per migration set. If you include versions and run top-ups without wiping, version purging must be disabled on the source.
  • The tool does not support merge ingestions, and a Cloud Acceleration Manager project can have at most 10 migration sets. Plan how brands and languages split across sets.
  • Adobe advises planning top-ups to avoid more than 48 hours of extraction and ingestion, and a content freeze for the final top-up. With many country teams, agree the freeze calendar early.

Brands, programs and pipelines

In Cloud Manager each program has one production environment and several non-production ones. For multi-tenant sites with their own release schedules and teams, Adobe's example setup is separate Sites programs, for instance two brands with separate development teams. Brands that share code, a release train and a team can stay in one program.

QuestionPoints to one programPoints to separate programs
Release scheduleBrands release togetherEach brand releases on its own timetable
TeamsOne development and content teamSeparate teams per brand or region
Code baseShared components with brand themesMostly brand-specific code
GovernanceCentral web team decidesBrands own their roadmap and budget
  • Front-end pipelines deploy JavaScript and CSS as a theme, and several can run at once, so brand styling can ship without a full-stack deployment. Only one full-stack pipeline can run per environment at a time.
  • Code from several Git repositories can be combined into one Cloud Manager repository, mapped to separate directories with a root pom.xml (or with Git submodules).
  • Site templates bundle structure, initial content and a theme, which helps when brands open new country sites after go-live.

If some sites move to Edge Delivery Services

Edge Delivery Services can run many sites from one code base (Adobe calls it repoless): code changes apply to every site that uses it. MSM can be used with Edge Delivery Services and AEM authoring once the repoless feature is enabled, with a one-to-one relationship between MSM sites and aem.live sites. In the Universal Editor, authors can break and reinstate inheritance with the MSM extension, which works for pages but not content fragments.

What to test after the move

  1. Roll out a change from each blueprint and check it reaches every live copy, and that cancelled inheritance still protects local content.
  2. Create a language copy and run a translation project end to end with your connector.
  3. Check experience fragments and their variations in every brand and language.
  4. Compare page counts and URLs per country site between 6.5 and Cloud Service.
  5. Time a large rollout with real authors working; that is where performance problems show first.

Questions

Does MSM work on AEM as a Cloud Service?

Yes. Blueprints, live copies, rollout configurations and inheritance are documented for AEM as a Cloud Service, and Adobe's MSM best practices apply.

Does the Content Transfer Tool keep live copy relationships?

Adobe's Content Transfer Tool documentation does not say. Test it with a representative brand and country before the full migration.

One Cloud Manager program or one per brand?

Adobe's example for brands with their own release schedules and teams is separate programs. Brands that share code, team and releases can share one.

Sources