AEM China — when Sitecore-class CMS stalls
AEM China is Limited when Adobe Experience Manager or Sitecore author and serve from overseas cloud, DAM, and identity hosts. Keep the CMS: remap origin, assets, and IMS — replace only when the job is not keep AEM or Sitecore.
AEM China is Limited when Adobe Experience Manager or Sitecore still author in Adobe or Sitecore cloud, serve DAM and static assets from overseas hosts, and leave identity (Adobe IMS / Sitecore identity) on those same overseas rails. Keep the CMS when origin, asset hosts, and identity remap. Replace only when the job is not keep AEM or Sitecore. This is an enterprise CMS China class — not a yes/no SKU.
What an enterprise CMS China stack actually is
Hard names your stack decision will use:
- Adobe Experience Manager China — AEM as a Cloud Service is Adobe-hosted author and publish, plus a built-in CDN. Authors sign in through Adobe IMS. Assets often leave through AEM Assets / Dynamic Media. This Guide does not invent an Adobe China license.
- Sitecore China — Same class, not a loophole. Sitecore cloud authoring (SitecoreAI) publishes through Experience Edge. DAM often rides Content Hub CDN. Identity is the Sitecore Cloud Portal.
- Failure class — Overseas authoring origin; DAM / static CDN hosts; identity hosts for authors. HTML 200 on the marketing URL is not a working journey — same class as website accessible in China.
- Usual keep path — Keep AEM or Sitecore as the CMS of record when you can place a China-reachable publish origin, remap DAM and static hosts, keep IMS / Sitecore identity off the visitor path, and file ICP when you terminate in Mainland China. Depth: host in Mainland China, ICP filing — domain DNS. Adobe or Sitecore cloud as the China visitor hostname is a capped architecture — not “enterprise CMS China launched.”
- WordPress contrast — WordPress in China is a plugin-CDN class: you can often keep the CMS by moving a self-hosted origin and cleaning deps. AEM Cloud Service / Sitecore cloud is closer to an origin you do not place the same way — remap publish and assets; do not paste the WordPress.com playbook onto Adobe cloud.
- Website-builder contrast — Wix / Framer-class builders are a SaaS site class. That remap is a China-reachable owned site, not “keep the builder URL.” Do not default an AEM stall to Wix, or a builder stall to AEM.
Vocabulary first. Next: what must be true before AEM or Sitecore stays the CMS at all.
What must be true before AEM or Sitecore stays
Missing a clear origin + assets + identity job stops your product team before a “keep AEM, add China” sprint is real work.
| Precondition | Why your process stalls |
|---|---|
| Job locked — keep AEM / Sitecore vs replace the CMS (WordPress keep-CMS, custom/static — not a website builder) | A builder or WordPress rebuild is staffed while the keep-CMS path was the job — or the reverse |
| Visitor origin named — Adobe / Sitecore cloud hostname vs China-reachable publish | Acceleration is bought for Adobe CDN or Experience Edge while Mainland China users still wait on those hosts |
| Honest DAM / static inventory — Dynamic Media, Experience Edge media, Content Hub CDN, fonts, tags; do not assume the template is local | “We kept AEM” still loads overseas asset hosts on every page |
| Identity scoped — Adobe IMS / Sitecore Cloud Portal for authors, not visitors | A visitor-IMS myth hides the real publish and DAM stall — or Mainland China authors cannot log in |
| ICP filing scoped when Mainland China termination is the publish plan — not claimed as a ban on overseas-only AEM | Filing starts too late, or teams treat overseas-only AEM as illegal |
| Mainland China vantage proof on authoring, DAM, identity, and the chosen publish origin — broadband + mobile; HQ laptop is not proof | Overseas QA “passes” while China users see a shell page — same class as website accessible in China |
| Hong Kong ≠ Mainland China | Regional hosting is reported as enterprise CMS China |
| TLD is not the CMS | A .cn domain is a registry / filing gate, not an AEM remap |
Product teams usually cannot treat “ship the same Adobe or Sitecore cloud site globally” as the Mainland China plan. Origin, assets, identity, and ICP are the floor.
AEM China keep path — origin, DAM, identity
| Stage | Decision / outcome |
|---|---|
| 1. Name the job | Keep AEM or Sitecore, or replace because the job is not keep this enterprise CMS? |
| 2. If keep the CMS | Rule Adobe / Sitecore cloud as the China visitor origin. Place a China-reachable publish origin (or China-facing site that does not depend on those cloud hosts for HTML and assets) |
| 3. Inventory DAM / static | Dynamic Media, Experience Edge media, Content Hub CDN, fonts, tags — list hosts, then self-host, drop, or remap each |
| 4. Scope identity | Visitors do not use Adobe IMS. Authors in Mainland China still need IMS / Sitecore Portal reach — or they author from HQ |
| 5. If Mainland China termination | Treat ICP filing as a go-live stall; bind host + domain DNS — see ICP filing — domain DNS |
| 6. If overseas-only AEM / Sitecore remains | Keep it as a capped architecture with known limits — not “AEM China launched” |
| 7. Prove from Mainland China | Broadband + mobile on origin, DAM, and identity hosts (or China Network Diagnostics) — measure Core Web Vitals from Mainland China, not only the HQ laptop |
| 8. Cut over, then re-test | China-reachable origin + remapped assets on the China journey. A later Dynamic Media URL or Edge embed can restore the stall |
Hard gate — keep CMS vs replace
Necessity: confusing these two jobs wastes the quarter — either you underfund origin / DAM / ICP, or you replace AEM when the CMS could have stayed.
| Job | AEM / Sitecore role | What must already be true |
|---|---|---|
| Keep AEM or Sitecore for a marketing / product site | Plan A after gates | China-reachable publish origin; DAM hosts inventoried; IMS off the visitor path; ICP filing in motion if you terminate in Mainland China |
| Keep a CMS you can self-host | Often WordPress keep-CMS — different class | Origin, plugin-CDN deps, and ICP — WordPress in China |
| SaaS website builder | Wrong remap | Wix / Framer-class is a site you do not own — not an enterprise CMS keep path |
| PaaS origin only | Not this Guide | Heroku in China is a PaaS origin class, not a DXP |
| “CDN the Adobe or Sitecore cloud site” | Myth as Mainland China plan | Origin reachability from the user network — not an HTML cache. Same geography lesson as SaaS performance in China |
Hard gate — Adobe / Sitecore cloud is not WordPress hosting China
Enterprise CMS China keep means a China-reachable publish origin plus remapped assets — not accelerating AEM as a Cloud Service or Experience Edge and calling it in-country. Hong Kong ≠ Mainland China — see host in Mainland China.
Why authoring, DAM, and IMS stall each other
Engineering constraints you must design around:
| Constraint | What breaks | What to do |
|---|---|---|
| Adobe / Sitecore cloud authoring origin | Editors at HQ may work while Mainland China users wait on Adobe-hosted publish or Experience Edge. | Place a China-reachable publish origin. Do not treat “try AEM, then Sitecore on timeout” as Plan A. |
| DAM / static CDN | HTML can return 200 while Dynamic Media, Experience Edge media, or Content Hub CDN never complete. | Inventory asset hosts. Remap or self-host what the China journey needs. |
| Adobe IMS / Sitecore identity | IMS is for Author, Admin, and Dev — not site visitors. Mainland China authors still stall if IMS / Cloud Portal is unreachable. | Keep identity off the visitor path. Prove author login where authors sit. |
| Built-in Adobe CDN / Experience Edge | A vendor CDN is not a filed Mainland China CDN. Faster HTML does not restore blocked DAM hosts. | Change the asset class, then tune delivery. |
| ICP filing vs overseas-only | Filing is required when public DNS terminates in Mainland China. Overseas-only AEM does not create that duty — and does not become a China launch. | If you terminate in-country, file before honest public publish (ICP filing — domain DNS). |
| WordPress or builder playbook pasted on AEM | Teams rebuild plugins or a Wix URL when the job was keep the enterprise CMS. | WordPress is plugin-CDN keep-CMS. Builders are SaaS sites. This Guide is origin + DAM + identity. |
Adobe-hosted publish ≠ China-reachable origin. An AEM Cloud Service site with Dynamic Media on the critical path is still a stalled AEM China journey.
HQ authoring OK → false confidence. Testers outside Mainland China never see the broken DAM, so the ticket never opens.
Hong Kong / Taiwan reported as enterprise CMS China → wrong stack. Outside-Mainland China performance is not ordinary Mainland China users at scale.
CDN without rewrite → partial win. Faster HTML does not restore blocked asset or identity hosts. Fix origin and DAM, then tune delivery.
What blocks teams that treat AEM as a geo toggle
- Yes/no SKU thinking — Product treats “Does AEM work?” as a geo toggle before origin, DAM, and identity are named.
- Sitecore-as-loophole — A second DXP is staffed after AEM stalls, as if Sitecore China used a different host class.
- Visitor-IMS myth — Teams “fix login” for site visitors who never used Adobe IMS.
- DAM assumed local — Dynamic Media, Edge media, and Content Hub CDN stay on every template after “we moved hosting.”
- ICP treated as an AEM ban — Filing is skipped on a real in-country origin, or demanded on an overseas-only architecture that was never going to file.
- WordPress or builder playbook pasted on Adobe cloud — Teams expect to self-host AEM Cloud Service like WordPress, or remap to Wix. Keep path is publish origin + assets.
- HQ laptop QA — Green screenshots from outside Mainland China close the ticket.
- Hong Kong conflated with Mainland China — Regional hosting is reported as AEM China working.
- No Mandarin / entity owner — Host bind, ICP filing, DAM allowlist, and vantage proof sit on rails most global teams lack.
What “fixed” means: Mainland China users can complete the journeys you claim on a China-reachable publish origin; overseas DAM / Edge hosts are gone from that client path; IMS / Sitecore identity is scoped to authors; ICP filing is done when termination is in Mainland China; residual overseas-only AEM is named and capped; replace is used only when the job is not keep AEM or Sitecore. Adobe or Sitecore cloud with a China marketing claim is not fixed.
China landing partner when enterprise CMS stalls
Most product teams exploring Mainland China entry need a China landing partner once they stop treating Adobe or Sitecore cloud as Plan A — to place a China-reachable publish origin, remap DAM hosts, bind ICP filing when termination is in Mainland China, and prove the journey from Mainland China broadband and mobile. Your team still owns whether AEM or Sitecore stays the CMS and which residual overseas line to keep; the partner path makes that keep-CMS stack executable when those rails are not already in-house.
What we can offer?
AEM China work for Mainland China is an origin + DAM + identity + ICP decision before any “keep the same Adobe or Sitecore cloud site” sprint. Chinaready helps your product team keep the CMS on rails that can actually load — or replace it only when the job is not keep AEM or Sitecore:
- China Readiness Assessment — Decide whether AEM or Sitecore stays Plan A, which authoring, DAM, and identity hosts sit on the critical path, and whether ICP filing is a go-live stall before a keep-CMS date.
- China Access Acceleration — Keep China-facing pages reachable and fast from Mainland China vantage so a remapped publish origin does not die on leftover Dynamic Media or Experience Edge hosts.
- China Product Hosting — Place China-critical publish origin where ICP adjacency, entity consistency, and a China-reachable host stay coherent after Adobe or Sitecore cloud leaves the visitor journey.
- Mobile App Distribution — Align any China app that still wraps an AEM or Sitecore content API with the same origin and DAM gates — not mistake a global Experience Edge feed for a China content plan.
Contact us when you need an AEM China keep-CMS path before you staff another Adobe cloud or Sitecore cloud sprint.
Frequently asked questions
Does AEM China work if we keep Adobe cloud publish?
Usually not as Plan A for ordinary Mainland China users. Adobe Experience Manager software is not categorically blocked, but Adobe-hosted authoring, DAM or static CDN hosts, and Adobe IMS typically stall the China journey. Keep the CMS on a China-reachable origin with remapped assets — do not treat “does AEM work?” as a yes/no SKU.
Is Sitecore China a different class from Adobe Experience Manager China?
No. Sitecore China stalls the same enterprise CMS China class — Sitecore cloud authoring, Experience Edge or Content Hub CDN assets, and Sitecore Cloud Portal identity. Do not staff a Sitecore rebuild as the China switch after AEM stalls.
When is enterprise CMS China ICP filing required?
ICP filing is a go-live stall when public publish terminates in Mainland China — not a claim that AEM or Sitecore is illegal on an overseas-only architecture. If DNS and origin stay outside Mainland China, you accept reach limits instead of that filing duty. The ICP filing — domain DNS Guide is the path once termination is in-country.
Does Adobe IMS block Mainland China site visitors?
Adobe IMS authenticates Author, Admin, and Dev users — not site visitors. Visitors stall on the publish origin and DAM or CDN hosts. Mainland China authors still need IMS reach to edit. Sitecore Cloud Portal identity is the same author-side class.
When should we replace AEM or Sitecore instead of keeping the CMS?
Replace only when the job is not keep AEM or Sitecore. WordPress can stay a CMS after origin, dependencies, and ICP line up. Website builders are the wrong remap — that is a SaaS site class, not an enterprise CMS keep path. A .cn domain is not a CMS.
Can product teams finish an AEM China keep path without Mainland China ops?
Usually no. China-reachable publish origin, DAM remap, ICP host bind when you terminate in Mainland China, and Mainland China vantage proof sit on rails most global teams lack. That is when a China landing partner becomes the realistic path.
