Migration › Knowledge Base › Rollout & decommission
Rollout & decommission
Advance like a rising tide, one section at a time, always keeping a way back, not a single dramatic flip of the whole site.
Mixed implementation is supported across pages: some sections on the Web SDK while others still run AppMeasurement. It is never supported on the same page, two libraries together cause duplicate identities and inflated metrics. So you migrate section by section, watch each, and only then move on.
Cutover itself is small: repoint the Production datastream from the validation RSID to the real one[21], and promote the Tags library Dev → Staging → Production. Decommissioning follows per validated section, disable the legacy Adobe Analytics and Experience Cloud ID Service extensions, remove residual AppMeasurement.js and VisitorAPI.js.
For your migration: your rollback is simply re-publishing the previous Tags library for a section, which is why phasing matters; it keeps the blast radius to one section. Document the rollback before go-live, not during an incident, and monitor unique visitors and key conversions through the first reporting cycle.
Roll out page-by-page with a documented rollback. Avoid big-bang cutovers on a large estate.
Advance like a tide
With parity proven, you don't flip the whole site at once. Mixed implementation is supported across pages, some sections on the Web SDK, others still on AppMeasurement, but never on the same page, where two libraries cause duplicate identities and inflated counts. So you migrate section by section, watch each, and only then advance. Start with low-risk, lower-traffic sections to keep the blast radius small.
The cutover itself
Cutover is small and deliberate: repoint the Production datastream from the validation RSID to the real production RSID[21], and promote the Tags library Dev → Staging → Production. Keep idMigrationEnabled on so returning visitors carry their ECID across the switch.
Decommission
Per validated section, retire the old world: disable the legacy Adobe Analytics and Experience Cloud ID Service extensions, remove residual AppMeasurement.js and VisitorAPI.js, and re-publish. Confirm in the Debugger that no legacy beacons fire and no s-object errors appear in the console.
Rollback and monitoring
Your rollback is simply re-publishing the previous Tags library for a section, which is why phasing and retained versions matter: reverting one section never touches the others. Document the steps and owners before go-live. Then monitor the first reporting cycle: unique visitors (the cliff check), key conversions, and parity against the retiring legacy data where they overlap.
A big-bang cutover of the whole site. When something's off, and something always is, the blast radius is everything at once, and rollback becomes a scramble instead of a calm, single-section re-publish.