How to Preserve Analytics During a Website Migration

Why analytics breaks during a migration

A website migration changes more than URLs and design. Forms may submit differently, checkout may move to another domain, components may load in the browser and consent behavior may be rebuilt. If tracking is copied at the end, the new website can launch with incomplete or incomparable data.

The safest approach treats measurement as part of the migration plan from the beginning.

Before development: record the current system

• Export the existing measurement plan and GTM container

• List GA4, advertising, CRM and dashboard dependencies

• Record primary conversions and where they are triggered

• Map domains, subdomains and third-party checkout steps

• Capture current campaign, channel and conversion baselines

• Identify existing data-quality problems that should not be migrated

• Save examples of reports leadership and marketing still use

Take a clean baseline for several normal business cycles where possible. You will need it to distinguish a tracking failure from a real change in traffic or conversion.

Decide what should remain comparable

Not every old event deserves to survive. Separate the migration into three groups:

• Keep unchanged: stable events and properties that support historical comparison

• Replace deliberately: events whose names or definitions need improvement

• Retire: tags and metrics no one uses or trusts

Document every change. If form_submit becomes qualified_lead, reports need a clear handover date and stakeholders need to know that the definitions differ.

Create a URL and journey map

Map old URLs to new URLs, including campaign landing pages, confirmation pages and redirects. Then map the complete journeys behind them.

• Landing page to form completion

• Product page to checkout and payment confirmation

• Content download to CRM record

• Booked meeting to scheduling provider

• Account registration across authentication domains

This reveals where campaign parameters, referral information and session identity could be lost.

Design the new data layer before rebuilding tags

The new site should emit business events from application code. Do not rebuild the old implementation around selectors and page text if the application already knows that a form or purchase succeeded.

For each event, define:

• Name and business meaning

• Exact trigger condition

• Required and optional parameters

• Consent category

• Destinations that receive it

• Owner and source of truth

• How it will be tested

Keep environments separate

Staging activity should not pollute production reports. Use dedicated GTM environments, test properties or explicit environment parameters. Make sure preview tools and test payment journeys cannot create real advertising conversions.

At the same time, staging must resemble production closely enough to test consent, client-side navigation, domains and third-party integrations.

Rebuild consent behavior as a tested system

• Set the default state before measurement tags initialize

• Map every tag to the agreed consent category

• Test accepted, rejected and changed choices

• Confirm behavior on direct deep links

• Test each market or regional rule

• Verify client-side navigation does not bypass the decision

Do not assume the new consent platform behaves like the old one. Record the intended behavior and test network requests.

Run the old and new implementations side by side

When feasible, send staging or limited production traffic into a separate validation property. Compare event counts, parameters and journeys before the full cutover.

Avoid sending two copies of the same production conversion to advertising platforms. Parallel measurement should be isolated and clearly labelled.

Launch-day tracking checklist

• Confirm the production GTM container and IDs

• Test the homepage and representative landing pages

• Complete every primary conversion

• Verify transaction IDs, values and currencies

• Check redirects and campaign parameters

• Test cross-domain and third-party steps

• Test consent states in a clean browser

• Check initial and client-side page views

• Confirm robots, canonical URLs and redirects separately from analytics

• Verify that dashboards receive the expected data

Monitor after launch

Do not wait for a monthly report. Review tracking immediately, again after the first full processing window and through the first normal business cycle.

• Traffic by channel and landing page

• Primary conversions and conversion rate

• Unknown or not set values

• Self-referrals and unexpected referral sources

• Device and browser gaps

• CRM or order totals against analytics

• Advertising-platform conversion delays

• Website errors and Core Web Vitals

Annotate the launch date in reporting tools. Keep the old reports and implementation notes available until the new data is trusted.

Common migration mistakes

• Copying the GTM snippet without rebuilding application events

• Changing event definitions without telling report owners

• Launching new URLs without checking campaign redirects

• Counting button clicks instead of successful outcomes

• Testing only full page loads on a single-page application

• Mixing staging and production traffic

• Forgetting embedded forms or external checkout

• Publishing both old and new conversion tags

• Removing the old site before collecting a baseline

Make analytics part of the migration acceptance criteria

A migration is not complete when the pages render. It is complete when customers can finish key journeys, the team can measure those journeys and the numbers reconcile with business systems.

Our Web Performance & Growth Engineering service can handle the measurement plan, data layer, GTM, GA4, advertising tags, consent behavior and post-launch validation. For the broader project checklist, see our website migration guide .