Analytics Continuity Through a CMS Cutover: Don’t Lose Your Baseline
Four months after launch, someone pulls the year over year traffic chart for the quarterly business review and there is a cliff in it. Not a dip. A cliff, dated to the week of the cutover. The site itself is fine: rankings held, the redirects held, every page is where it should be. What broke was the measurement, and nobody caught it because the dashboards kept rendering the whole time.
Analytics continuity is won or lost in discovery, months before a tag is touched. eight25 is a certified Contentful and Contentstack partner that treats it as a discovery deliverable on Fortune 500 replatforms: a tag inventory, a data layer contract the new CMS is required to honor, and a measurement plan, all signed off before build starts, so GA4, Adobe Analytics and GTM keep feeding the same properties clean data from cutover day one.
Analytics continuity breaks in the data layer while the tags keep firing
The tag is almost never the fragile part. GA4 keeps collecting after cutover. Adobe keeps collecting. The pipes are intact. What changed underneath them is the contract feeding those pipes, because a new CMS emits a new dataLayer, and it emits it with new field names, new event triggers, and new page-type metadata that nobody wrote down as a requirement.
The failure is quiet, which is why it gets expensive. Collection does not stop, so no alert fires. Reports still populate, so nothing looks broken in a weekly skim. Fields degrade one at a time:
| dataLayer field | Legacy CMS emitted | New front end emits | Downstream effect |
|---|---|---|---|
| pageType | product-detail | productDetail | GA4 content grouping resets to (not set); every page-type trend line starts over |
| contentGroup | on every template | only on the templates that were ported first | Partial data, so the report looks plausible rather than empty |
| formName | Emitted on form submission | Replaced by form_id in the new component library | Existing tags or marketing-automation mappings that expect form_name stop receiving the value, weakening form and lead-source reporting |
| userLoggedIn | Boolean available when the initial page event fires | Available only after client-side authentication state resolves | Early page and engagement events may be recorded without the authenticated-user classification, causing that audience segment to be undercounted |
A field that goes missing is easy to find. A field that changes shape is not, because the number it produces is still a number.
Consent is another common failure point. A replatform may preserve the existing CMP, replace it, or simply reconnect the same banner to a new front end. In every case, the consent state must be available before consent-dependent tags execute, and consent updates must reach the tag layer correctly. Monitor both consent-state distribution and collection volume during launch; session totals alone may hide a regional, device-specific or category-specific consent failure.
Not every schema change is a mistake. If the old event taxonomy was wrong, if it accumulated a decade of ad hoc events that no one can define, a replatform is a reasonable moment to fix it. The difference is between a change somebody decided on and wrote down, and a change that happened because a developer named a variable differently.
History lives in the property, not the website
Analytics history is associated with the analytics property or report suite, not with the CMS or website code. A CMS cutover therefore does not delete historical GA4 or Adobe Analytics data. However, GA4 does not provide a standard way to merge the reporting history of one property into a different property, and creating a new Adobe report suite similarly creates a reporting break unless the two periods are deliberately bridged outside the native reports.
Teams can unintentionally abandon continuity by sending post-cutover data to a new property or report suite without a documented reason. Historical data may still remain accessible in the original system or an export, but native before-and-after trend reporting becomes harder. The default decision should be to retain the existing property or suite unless a new measurement strategy makes a documented reset preferable.
Two retention and export details should be resolved before the legacy implementation is retired:
- GA4: Standard properties support user-level retention settings of 2 or 14 months. Other event data can be retained for 2 or 14 months in standard properties, while eligible Analytics 360 properties may offer longer periods. These controls principally affect non-aggregated analysis such as Explorations and funnels; they do not remove the standard aggregated reports on the same schedule. If hit-level history is required in BigQuery, enable and validate the export early because it should not be treated as a retroactive backup of data collected before the link existed.
- Adobe Analytics: Confirm the organization’s contracted retention period, which may differ from Adobe’s standard retention policy, and export any hit-level history that must remain available outside Adobe. Preserve a dated dictionary of eVars, props, events, classifications and processing rules. Processing-rule changes apply when data is collected and are not retroactive, so documentation is essential for interpreting historical data after the implementation changes.
A documented break is sometimes the more honest choice. If the KPI framework, event taxonomy or analytics platform is changing materially, forcing two incompatible schemas into a single trend line can be more misleading than acknowledging the discontinuity. In that situation, retain or export the historical record, document the old-to-new metric definitions, annotate the change in every affected dashboard, and identify which comparisons remain valid. A limited bridge table is still useful for metrics with genuinely equivalent definitions, even when complete continuity is impossible.
The data layer contract is the decision that carries everything else
If the tag layer reads from a stable, versioned schema implemented by the presentation layer, most tags can remain insulated from the underlying CMS change. In a headless architecture, this boundary is particularly clear: the CMS exposes structured content and stable entry identifiers, while the front end translates that information and user behavior into a measurement schema. That separation makes continuity easier to govern, but only when the data layer contract is treated as a tested product interface rather than informal documentation.
A contract here means a field-level specification with an owner, a version number and a QA gate. Diagrams do not survive contact with a sprint.
| Field | Type and allowed values | Emitted where, by what | Consumed by |
|---|---|---|---|
| page_type | enum: home, product, solution, blog, resource, locale_home | On every initial or virtual page view, emitted by the presentation layer from the route and CMS content model | GA4 content grouping; Adobe eVar |
| locale | ISO code: en-US, de-DE | On every initial or virtual page view, supplied by the routing or localization layer | GA4 custom dimension; Adobe prop or eVar |
| content_id | CMS entry UID | Added by the presentation layer from the Contentful or Contentstack entry returned by the delivery API | Joins analytics performance back to the CMS entry |
| form_id | string, stable across locales | Emitted by the form component on a successful submission or another explicitly defined form event | GA4 key event reporting; marketing-automation attribution |
| cta_location | enum: hero, inline, sticky, footer | cta_click, from the component library | in-page conversion path analysis |
| consent_state | object | Set by the CMP integration before consent-dependent tags execute and updated when consent changes | Tag gating and consent-state monitoring |
Enumerated values reduce the risk of values such as product_detail and product-detail appearing as separate categories. When the schema is enforced through types, automated tests or runtime validation, an invalid value can be caught before release rather than discovered in reporting. Engineering should own the implementation and versioning, while analytics or marketing owns the business definitions and acceptance criteria. Neither team can protect continuity alone.
content_id earns its place for a different reason. Carrying the CMS entry identifier into the data layer lets an editor ask which entry drives pipeline instead of which URL does, and entry IDs survive the URL churn a replatform brings.
GA4, GTM and Adobe each fail in a different way
The contract tells each platform what to read. Getting each one to read it is three separate jobs, and teams that treat them as a single workstream usually miss the hard one.
| Layer | Survives the replatform | Breaks quietly | What the work is |
|---|---|---|---|
| GA4 property | Property ID, reporting history, configured events, custom definitions and audiences, subject to their existing settings | Tags may continue sending events while renamed parameters, route changes or duplicate page-view logic alter reporting | Continue using the intended property; map the new schema; test custom parameters, key events, referrals and SPA routing |
| GTM container | The existing container, versions and workspace history can remain available | Variables and triggers may still reference legacy DOM selectors, URLs, event names or data-layer paths | Export a versioned backup; audit dependencies; update mappings in a controlled workspace; preview and review the import or publish diff |
| Adobe Analytics | The report suite, historical data and existing processing rules can remain when the same suite is retained | The browser implementation may stop supplying the context data, eVars, props or events expected by those rules | Audit the implementation and processing rules together; test against a development suite or controlled environment before production |
| Consent / CMP | Vendor account, policies, cookie records and configuration may survive, depending on the implementation | Timing, category mapping, region detection and tag-gating behavior can change on the new front end | Reconnect and test the CMP before cutover; verify default state, updates, persistence and region-specific behavior |
Start by preserving the current GTM configuration. Export the relevant container version or workspace as JSON and store it as a versioned backup before changing variables or triggers. For a partial export, GTM warns when selected items depend on excluded tags, triggers or variables; if the export continues, references to missing tags and triggers are removed, while variable references are preserved. During import, review the detailed change preview carefully. Choosing Overwrite removes the existing tags, triggers and variables from the selected workspace and replaces them with the imported configuration, while Merge allows conflicts to be overwritten or renamed. GTM creates a new container version before an overwrite, but the choice can still disrupt active work if it is made in the wrong workspace.
Adobe implementations often require a deeper audit because several layers work together: the browser implementation, data elements or context data, eVars, props and events, processing rules, and the destination report suite. The report suite and its processing rules can remain in place, but the new front end must continue supplying the values and events those rules expect. Every unaudited dependency is therefore a potential data gap, even when the report suite itself is unchanged.
A replatform may also coincide with a move from AppMeasurement to Adobe Experience Platform Web SDK, which creates two separate migration risks. If AppMeasurement and Web SDK both send the same page views or interaction events to the same report suite, those events can be duplicated; dual collection must therefore use deliberate routing, filtering or comparison rules rather than allowing both implementations to send identical production hits. Adobe supports using the Web SDK data object to pass Analytics variables without requiring a full XDM schema during the first migration stage, which makes a phased move possible. Track the CMS cutover and SDK migration as separate workstreams so failures can be isolated and tested independently.
Prove continuity against a baseline you captured before the freeze
“Tags are firing” is not a completion criterion. Firing tags with a broken schema can still produce unusable data. Completion means comparing the new implementation with a documented pre-cutover baseline and investigating differences outside an agreed tolerance. The figures below are illustrative starting points, not universal thresholds; each program should set them using normal traffic variability, business impact, consent behavior, campaign schedules and data latency.
| Metric | Baseline source | Illustrative investigation threshold | Example severity |
|---|---|---|---|
| Sessions per day by channel | trailing 28 days pre-freeze | ±5% | P2 |
| Key event volume, for example form_submit | trailing 28 days | ±2% | P1 |
| Collection coverage: indexable URLs firing a page view | crawl joined to collection | ≥99% | P0 |
| Consent grant rate | trailing 28 days | ±3 percentage points | P1 |
| Campaign-tagged sessions | trailing 28 days | ±5% | P1 |
| Revenue or pipeline events | trailing 90 days | ±2% | P0 |
Attach that table to the launch war room, next to performance and error monitoring, and make a tag-health check part of the first-hour rollback criteria. On enterprise cutovers we run a war room with 24/7 coverage for the first 48 hours and a 30-day hypercare period governed by a P0 to P4 severity framework. Analytics validation belongs inside that framework.
Redirect behavior belongs in the launch plan because attribution can break even when tags fire correctly. If a redirect fails to carry required campaign parameters to the destination URL, downstream analytics may lose the campaign context and classify the session differently. On NetApp’s Tridion-to-Contentstack migration, approximately 14,000 pages across 10 languages moved to a Next.js front end hosted on Vercel and served behind Akamai, with Adobe Analytics and Adobe Target among the connected systems. That architecture made redirect and edge behavior part of both SEO and measurement validation. The following rules illustrate what should be tested on any comparable cutover:
| Edge rule | Wrong behavior | Correct behavior | What it protects |
|---|---|---|---|
| Query string on redirect | ?utm_source=li stripped on the 301 | parameters forwarded intact to the destination | all paid and email attribution |
| Locale prefix rewrite | /de/ collapsed to the default locale | locale preserved through the redirect chain | per-market reporting |
| Redirect chaining | Several redirects occur before the final 200 response, with parameters or locale information potentially lost between hops | Resolve the legacy URL to the final canonical destination in one controlled redirect wherever practical | Campaign-parameter continuity, crawl efficiency, latency and easier redirect QA |
| Trailing slash and case | both variants resolve 200 | one canonical form, the other 301s to it | duplicate page-view splitting |
A side-by-side validation period requires real budget and calendar time, and its scope should reflect measurement risk rather than an arbitrary tag count. A low-complexity, single-locale site with limited marketing integrations may be adequately validated in staging followed by intensive production monitoring. A multi-locale estate connected to paid media, a CDP, personalization or marketing automation usually warrants a more controlled comparison because production consent, identity, routing and campaign behavior can be difficult to reproduce fully in staging.
Who owns analytics continuity in the SOW
Ask one question, and ask for a name: who owns analytics continuity, and which deliverable is theirs? “Marketing handles the tags” is how organizations lose a year of trend data. Analytics is an integration surface, exactly like search or a CRM connector, and it fails the same way when it sits outside the statement of work.
Three artifacts belong in the discovery phase, with dates against them:
- Tag inventory. Every active GTM tag, trigger and variable; relevant Adobe processing rules; every GA4 event, key event and custom definition. Classify each item as retain, revise or retire, and record an owner for the decision.
- Data layer contract. A field-level specification owned jointly by analytics and engineering, versioned with the implementation, and enforced through automated tests or release checks.
- Measurement plan. The definition, trigger conditions, parameters, business purpose and reporting owner for each event. This document makes it possible to decide what should not be carried into the new implementation.
Then document three decisions: whether the existing property and report suite will be retained, which historical exports are required and when they will begin, and how pre- and post-cutover data will be compared. The validation approach may range from staging plus intensive launch monitoring to a controlled dual-run period, but it should always include written acceptance thresholds and named owners.
Frequently Asked Questions
Will I lose my analytics history when I migrate to a new CMS?
Not because of the CMS change itself. GA4 history remains associated with the GA4 property, and Adobe Analytics history remains associated with the report suite. The reporting break occurs when the new implementation sends data to a different property or suite without a deliberate continuity plan. Before cutover, confirm the destination IDs, retention settings and required exports. In GA4, retention controls affect user-level and event-level data used in non-aggregated analysis, while standard aggregated reports follow different behavior. If hit-level history is required in BigQuery, enable and validate that export before relying on it as the historical record.
How do you keep GA4 data accurate through a website replatform?
Write a data layer contract in discovery: a field-level specification of the dataLayer schema the new CMS is required to emit, with enumerated values, an engineering owner, and a build check that fails when a required field is missing. Tags read from that schema, so they do not care that the platform changed. Then validate against a documented pre-migration baseline during a parallel-tracking window rather than declaring the work done because tags fire.
How do you migrate a Google Tag Manager container to a new CMS?
Export the current GTM container version or workspace as JSON and store it as a versioned backup. Reuse the existing container where appropriate, then update variables and triggers against the new data layer, routing and component behavior. If importing configuration, review partial-export dependency warnings and the detailed import preview. Choose Merge or Overwrite deliberately: Overwrite removes the existing tags, triggers and variables in the selected workspace and replaces them with the imported configuration, while Merge gives you conflict-handling options.
Why is Adobe Analytics harder to preserve than GA4 in a migration?
Adobe Analytics can require more implementation-specific auditing because the browser code, data elements or context data, eVars, props, events, processing rules and report suite work together. The report suite and historical data can remain, but the new front end must continue supplying the values expected by the existing configuration. If Web SDK is introduced during the same program, test it as a separate workstream and prevent AppMeasurement and Web SDK from sending duplicate events to the same report suite. Adobe’s data object supports a phased move without requiring a full XDM schema at the first stage.
How do I find a partner who will actually protect analytics through a cutover?
Ask which analytics artifacts appear in their discovery phase with dates attached, and ask who owns them by name. A partner who answers with a tag inventory, a data layer contract and a measurement plan has done this before. A partner who says analytics is handled at QA has not. eight25 runs a two to four week discovery sprint that produces those three artifacts alongside the content inventory and integration map, and treats collection monitoring as a first-hour rollback criterion in the launch war room rather than a post-launch check.
Before your cutover date is set
If a replatform is already scheduled and analytics is not yet in the scope document, the useful next step is a short audit rather than an RFP: what is in the container today, which of it anyone still reads, and what the new CMS would have to emit for the tag layer to survive the change.
For many organizations, that assessment can be completed as a focused discovery workstream before the main build begins. The output should include a prioritized tag inventory, a data layer contract the engineering team can implement, and an agreed tolerance table that gives business and technical owners a shared launch decision framework.