Analytics checks every migration should include | Lillian Purge

Analytics checks every migration should include

Analytics is the safety net of any site migration. From experience, it is also the part that is most often underprepared and underchecked. I have seen migrations that looked technically perfect and SEO sound, yet weeks later nobody could confidently answer a simple question like are we actually losing enquiries or is tracking broken. That uncertainty is avoidable and in my opinion analytics checks are not optional add ons, they are a core part of responsible migration planning.

A site migration is not just a change in URLs or design. It is a change in how users interact with your site and how data is captured, interpreted, and trusted. If analytics breaks or becomes unreliable during a migration, you lose visibility at the exact moment you need it most. Decisions become emotional instead of evidence based and that is when poor calls are made.

This article explains the analytics checks every migration should include. It is written from real world experience handling migrations across service businesses, ecommerce, education, and high trust industries. I will walk through what to check before launch, at launch, and immediately after, why each check matters, and what problems tend to appear when these steps are skipped.

Why analytics matters more during migrations than normal operation

In day to day marketing, analytics helps you optimise. During a migration, analytics helps you survive.

From experience, migrations introduce noise. Rankings fluctuate, traffic patterns change, and user behaviour shifts. Without clean analytics, you cannot tell whether changes are normal migration volatility or genuine problems that need intervention.

Analytics during a migration is not about long term trend analysis. It is about diagnostic clarity. You need to know whether pages are being viewed, whether conversions are firing, and whether data continuity has been preserved.

I think the biggest mistake is assuming that if analytics worked before, it will work after. That assumption is wrong more often than people realise.

Understanding what analytics continuity actually means

Analytics continuity means you can compare before and after data with confidence.

From experience, this requires more than having a tracking tag present. It means that sessions, users, conversions, events, and sources are being measured in the same way as before, or at least in a way that is understood and documented.

If your migration changes URL structures, page titles, event names, or tracking logic without accounting for it, comparisons become misleading.

You might think traffic has dropped when in reality it is being attributed differently. Or you might think conversions have stopped when they are simply not being recorded.

Continuity is about interpretation, not just collection.

Confirming which analytics platform is the source of truth

Before any migration, you need clarity on which analytics platform you are relying on.

From experience, many organisations have multiple tools installed. Google Analytics, GA4, Universal Analytics legacy setups, tag managers, CRM tracking, and sometimes third party scripts.

During a migration, this complexity increases risk. You need to define which platform is the primary source of truth for decision making.

Once that is clear, migration checks should prioritise that platform first. Secondary tools can be validated later.

Without a clear source of truth, post migration analysis becomes confusing very quickly.

Auditing existing analytics setup before migration

You cannot validate what you do not understand.

From experience, one of the most overlooked steps is auditing the existing analytics setup before migration. People assume they know how it works but often they do not.

Before migration, review which tags are installed, how they are triggered, what events exist, and how conversions are defined. Document this clearly.

This pre migration snapshot becomes your baseline. Without it, you cannot tell whether changes after launch are due to migration issues or pre existing configuration problems.

Capturing baseline data and benchmarks

Baseline data is essential.

From experience, you should capture key metrics for a defined period before migration. This includes sessions, users, conversions, conversion rates, top landing pages, and top traffic sources.

This baseline should be saved and shared. Screenshots, exports, or dashboards are all useful.

After migration, you will compare against this baseline repeatedly. If you do not capture it in advance, you are relying on memory and assumptions.

I think this is one of the simplest steps that prevents the most confusion later.

Verifying analytics tracking on the staging environment

Staging environments are often overlooked in analytics planning.

From experience, many teams either do not install analytics on staging at all or they install it incorrectly.

Staging analytics does not need to pollute your main data. It can use a separate property or be filtered.

The purpose is validation. You need to confirm that tracking fires correctly on the new templates before users ever see them.

Testing analytics only on live after launch is unnecessary risk.

Ensuring tracking IDs and containers are correct

Simple mistakes cause big problems.

From experience, migrations often result in the wrong tracking ID or tag manager container being deployed. This can happen when environments are mixed up or templates are reused.

Before launch, verify that the correct tracking IDs are present on the staging site and that they match the intended production setup.

After launch, verify again on the live site. Do not assume deployment went as planned.

This single check has saved more migrations than any advanced analysis.

Checking tag firing across page types

Not all pages are equal.

From experience, analytics tags may fire correctly on some templates and not others. Homepages, service pages, blog posts, category pages, and forms may all use different layouts.

During a migration, new templates are introduced and old ones removed. Each template must be tested.

Use tag debugging tools to confirm that pageview and event tags fire consistently across all key page types.

Missing tracking on a high traffic template can skew data dramatically.

Validating consent and cookie logic

Consent management often breaks during migrations.

From experience, new designs or scripts can interfere with cookie banners or consent logic. This can result in analytics not firing for some users or firing incorrectly.

Check that consent prompts appear as expected and that analytics behaviour aligns with user choices.

Consent issues can cause sudden drops in recorded traffic that look like SEO problems but are actually compliance related.

Understanding this distinction is critical.

Confirming pageview tracking logic

Pageview tracking is the foundation.

From experience, migrations to modern frameworks often change how pageviews are tracked. Single page applications, dynamic routing, or client side navigation can require additional configuration.

Confirm that pageviews are recorded on every page change, not just initial load.

If pageviews are undercounted, engagement metrics and conversion funnels become unreliable.

Monitoring URL reporting consistency

URL changes affect reporting.

From experience, migrations often introduce new URL structures. Analytics reports based on old URLs may no longer align.

Confirm that new URLs appear correctly in reports and that filters or views are updated accordingly.

If you rely on specific URL patterns for reporting, those need to be revised as part of the migration.

Ignoring this leads to false conclusions about performance.

Checking referral and source attribution

Source attribution often shifts after migration.

From experience, protocol changes, domain changes, or redirect misconfigurations can cause traffic to be misattributed as referral or direct instead of organic.

Immediately after launch, monitor traffic sources closely. Look for unusual spikes in direct traffic or self referrals.

These patterns often indicate tracking or redirect issues rather than genuine behaviour change.

Monitoring self referral issues

Self referrals are a common migration problem.

From experience, they occur when analytics sessions are split by redirects, cross domain issues, or missing configuration.

Self referrals inflate session counts and distort conversion attribution.

Check referral reports for your own domain appearing as a source. If it does, investigate immediately.

Fixing self referral issues early preserves data integrity.

Validating cross domain and subdomain tracking

Migrations sometimes introduce new domains or subdomains.

From experience, this includes moving to www, adding app subdomains, or integrating third party booking systems.

Cross domain tracking must be configured correctly to maintain session continuity.

If not, users appear to start new sessions mid journey. Conversion paths break and performance looks worse than it is.

Cross domain validation should be part of every migration checklist.

Testing conversion tracking thoroughly

Conversions are what matter most.

From experience, migrations often break form submissions, ecommerce tracking, or event based conversions.

Test every conversion path manually. Submit forms, complete purchases, trigger phone clicks, and verify that conversions are recorded correctly.

Do this in staging if possible and again immediately after launch.

Broken conversion tracking can cause panic and poor decisions if not identified quickly.

Verifying event naming and consistency

Event tracking often changes during migrations.

From experience, new designs introduce new event names or alter existing ones. This can fragment reporting.

Review event lists before and after migration. Ensure key events are still recorded and that naming conventions are consistent.

If event names change intentionally, document it so comparisons are interpreted correctly.

Without this clarity, engagement analysis becomes meaningless.

Checking funnel and goal definitions

Funnels rely on structure.

From experience, migrations often change URLs or steps within funnels. Old funnel definitions may no longer reflect reality.

Review and update funnel and goal configurations as part of the migration process.

Do not rely on legacy setups without validation.

A funnel that silently breaks gives false reassurance or false alarms.

Monitoring real time data at launch

Real time reports are useful at launch.

From experience, checking real time analytics during and immediately after launch confirms that data is flowing.

Look for active users, pageviews, and events.

While real time data is not precise, a complete absence of activity is a red flag that needs immediate attention.

Comparing analytics data with server logs or Search Console

Analytics should not be viewed in isolation.

From experience, comparing analytics traffic with Search Console clicks or server logs helps validate accuracy.

If Search Console shows impressions and clicks but analytics shows nothing, tracking is likely broken.

If analytics shows traffic but Search Console does not, attribution or filtering issues may exist.

Cross checking sources improves confidence in your conclusions.

Monitoring bounce rate and engagement changes

User behaviour metrics often shift after migration.

From experience, some change is normal due to design updates. However, extreme changes can indicate issues.

Monitor bounce rate, time on page, and pages per session closely.

Sudden spikes in bounce rate may indicate broken layouts, slow loading, or tracking errors.

Interpret behaviour changes carefully and in context.

Watching top landing pages closely

Landing pages tell you where issues concentrate.

From experience, after migration you should monitor performance of top landing pages individually.

Look for pages that lost traffic disproportionately or stopped converting.

These pages often reveal specific problems like broken redirects, missing content, or tracking gaps.

Fixing issues on a few key pages can stabilise overall performance.

Checking internal search tracking

If you use internal search tracking, validate it.

From experience, migrations often break internal search tracking or change query parameters.

Internal search data is a valuable indicator of user confusion. Losing it removes an important feedback loop.

Confirm that internal search queries are still captured correctly.

Monitoring error pages and 404 interactions

Analytics can reveal user facing errors.

From experience, track pageviews of 404 or error pages after migration. An increase indicates broken links or missed redirects.

Users encountering errors are frustrated and likely to leave.

Fixing these issues quickly protects both user experience and SEO.

Checking call tracking and offline conversions

Many businesses rely on call tracking.

From experience, migrations often disrupt call tracking scripts or number swapping logic.

Validate that phone numbers display correctly and that calls are attributed as before.

Offline conversion tracking errors can make marketing appear less effective than it is.

Reviewing filters and views

Analytics filters can cause silent data loss.

From experience, migrations sometimes change URL patterns or hostnames in ways that conflict with existing filters.

Review filters carefully to ensure they still apply correctly.

Incorrect filters can exclude valid traffic or include staging traffic.

Monitoring data sampling and thresholds

Large sites may encounter sampling or threshold issues.

From experience, migrations that increase traffic or event volume can trigger new thresholds in analytics tools.

Be aware of sampling indicators and understand how they affect reporting.

Do not mistake sampled data anomalies for real performance changes.

Documenting all analytics changes

Documentation matters.

From experience, migrations often involve multiple analytics changes. Without documentation, later analysis becomes guesswork.

Document what changed, when, and why.

This record is invaluable when explaining performance trends to stakeholders.

Communicating analytics expectations internally

Stakeholders need context.

From experience, executives and teams often expect immediate clarity after migration.

Explain in advance that some metrics may fluctuate or be delayed while tracking stabilises.

Setting expectations reduces panic and allows for thoughtful analysis.

Establishing a post migration analytics monitoring schedule

Monitoring should be structured.

From experience, daily checks are appropriate in the first week, then every few days for the next month.

Define who checks what and how issues are escalated.

Ad hoc monitoring leads to missed signals.

Knowing when analytics issues are SEO issues

Not all drops are SEO related.

From experience, many post migration traffic drops are caused by analytics issues rather than ranking losses.

Distinguishing between the two quickly prevents unnecessary SEO changes.

Analytics checks help isolate the cause.

Learning from analytics anomalies

Anomalies are learning opportunities.

From experience, investigating unexpected data often reveals deeper issues in site structure, UX, or tracking.

Treat anomalies as signals rather than annoyances.

This mindset improves both analytics and SEO maturity.

Avoiding knee jerk reactions based on incomplete data

One of the biggest risks is overreacting.

From experience, businesses often make major changes based on a few days of data after migration.

This can compound problems rather than solve them.

Analytics checks exist to provide confidence, not panic triggers.

When to seek specialist help

Some analytics issues are complex.

From experience, cross domain tracking, server side tagging, or large scale event schemas may require specialist input.

Do not hesitate to involve experts if issues persist.

The cost of delay often outweighs the cost of help.

Final thoughts from experience

Analytics checks are not a technical formality during migrations. They are a decision making lifeline.

From experience, migrations that include thorough analytics validation recover faster, experience less panic, and lead to better long term outcomes.

I think the most important principle is this. You cannot manage what you cannot measure and you cannot measure what you have not protected.

When analytics is treated as a first class part of migration planning, SEO becomes safer, clearer, and far more controllable.