Backing up your Google Analytics 4 and Search Console data before a migration

A website redesign or migration is judged on one point: are traffic and conversions still there after the launch? To answer, you need a baseline, and that baseline is prepared before the migration, not after. Two Google tools provide it: Google Analytics 4, which measures what happens on the site, and Google Search Console, which measures what happens before, in the search results. Their data is also useful upstream: it shows which pages receive visits, clicks and links, and therefore which ones must on no account lose their redirect.

This article covers Google Analytics 4. Universal Analytics stopped collecting data in July 2023 and its data was deleted in 2024: the old export methods, such as the Google Analytics add-on for Google Sheets, no longer apply. Backing up measurement data complements backing up the files, the database and the configuration: see our list of what to back up before a migration.

Google Analytics 4 attaches data to a property and a data stream, not to an address. As long as the new version of the site carries the same tag (the same measurement ID), the history continues in the same property, even if the domain name changes. You therefore do not lose your data by migrating, provided you do not create a new property without good reason.

Page reports, on the other hand, are read by path or by address. After the migration, each new URL appears on its own row, and the old row stops receiving visits. To compare a page before and after, you need to know which old URL corresponds to which new one: that is exactly what your redirect plan describes.

In short, here is what is kept and what is at risk:

• kept: the property's history, the standard reports, the key events already recorded, the links with Search Console, Google Ads or BigQuery;
• at risk: the detailed data used by explorations, deleted beyond the retention period you have chosen; key events that depend on a URL (a thank-you page whose address changes); pages of the new version where the tag was forgotten; campaign parameters (utm_source, utm_medium, etc.) if a redirect strips the query string.

There is no need to export everything. Focus on what will help you decide and compare:

• landing pages, with sessions, users and key events, for all traffic and for the "Organic Search" channel group alone;
• page views by page path, to identify content viewed during the visit and not only on arrival;
• key events by page and by source, to know where conversions happen;
• referring sites, which show the external links that actually bring visits;
• a period long enough to cover your seasonal variations, and the same period of the previous year if you have it.

Since 2024, Google Analytics 4 has called "key events" what it used to call "conversions"; the term "conversions" is now reserved for Google Ads.

In a standard Google Analytics 4 property, detailed event-level data is kept for 2 months by default, or 14 months if you choose so. The setting is in the admin area, under "Data collection and modification", then "Data retention".

This period does not apply to standard reports, which rely on aggregated data and keep the property's history. It does, however, limit explorations: with 2 months of retention, an exploration cannot go back any further. Switch to 14 months as early as possible. The change only applies going forward: it does not recover data that has already been deleted. That is one more reason to export your explorations before the migration and to enable the BigQuery export.

In a standard report (for example "Landing page", in the Engagement section), first choose the date range, then add a comparison or a filter if needed, for example on the default channel group "Organic Search". The "Share this report" icon, at the top right, offers "Download File", in PDF or CSV format.

The CSV can be reworked in a spreadsheet, the PDF can be shared with a client or a team. Before each download, check the date range and the filters applied: a forgotten filter gives a partial export without anything in the file name to show it. Name your files with the date and the scope, and store them in a shared folder of the migration project.

Explorations, in the "Explore" menu, allow more precise tables than standard reports: a free-form exploration with the landing page as rows, sessions, users and key events as values, and a filter on the channel. They can be exported from the exploration's export menu, in particular to Google Sheets or as CSV.

Two limits to be aware of: an exploration cannot go back beyond the event data retention period, and on large volumes it may be sampled, which is shown by the data quality indicator at the top of the exploration. For a high-traffic site, shorten the date range or use BigQuery.

Google Analytics 4 can export its raw data, event by event, to BigQuery, Google Cloud's data warehouse. The link is set up in the property's admin area, among the links with other Google products, and it is available for all properties, including free ones. The daily export is free on the Analytics side; storage and queries in BigQuery fall under Google Cloud billing, with a free allowance each month.

What you need to know before a migration:

• the export is not retroactive: it starts on the date the link is created. Enable it several weeks before go-live so that you have a reference period;
• for a standard property, the daily export is capped at one million events per day;
• in the BigQuery sandbox (without billing enabled), tables expire automatically after 60 days: enable billing if you want to keep them;
• exported data no longer depends on the property's retention period: it is the only way to keep event details over the long term.

BigQuery requires the ability to write SQL queries. If nobody in the team can, enable the export anyway: the data will be there on the day you need it.

Looker Studio, Google's free dashboard tool, connects directly to Google Analytics 4, Search Console, BigQuery and Google Sheets. Before the migration, prepare a dashboard that tracks organic sessions, landing pages and key events, with a comparison to the previous period: on go-live day, it will be ready.

Be careful: Looker Studio is not a backup. It queries the sources every time it is displayed and does not store the data. It shows what the Analytics property or BigQuery still contains, nothing more.

Google Analytics 4 lets you add dated annotations, visible on report charts. Record the go-live date, the date the redirects were activated and any tagging change: in six months, nobody will remember why the curve moved on a given day.

Back up these annotations with a migration log kept outside Analytics, in the project folder: date and time of each step, version of the redirect plan deployed, corrections made afterwards. It will also help you read Search Console data, which has no annotations.

A migration often breaks tracking without anyone noticing. Before go-live, check on the staging site, then on the day itself in production:

• that the Google Analytics tag (or the Google Tag Manager container) is present on every template of the new version, and that it uses the same measurement ID;
• that key events defined from a URL (a thank-you page, a checkout step) target the new addresses;
• that the forms, buttons and carts that trigger events still carry the same IDs or classes;
• if the domain name changes or if the journey spans several domains, that the data stream's domain list and the list of unwanted referrals are up to date;
• that the links in your campaigns (emails, ads, social networks) point to the new URLs, rather than relying on a redirect that could lose the utm parameters.

The "Realtime" report and DebugView let you see events arriving during your tests. In the following weeks, compare key events by landing page with your exports: a sudden drop on one type of page more often points to a tagging problem than to a loss of rankings. Our article on SEO problems after a redesign helps you tell the difference.

Google Search Console gives, by page and by query, impressions, clicks and average position in Google. It keeps only the last 16 months, and no setting extends that period: what has not been exported is lost. For a migration, it is the most direct source of what Google sees and sends, page by page.

Also link your Search Console property to Google Analytics 4, from the property's admin settings, to see this data in Analytics. This link does not replace the exports: it only displays the data that Search Console still holds.

In the "Performance" report, "Search results" tab, choose the longest period available, display clicks, impressions, CTR and position, then export the "Pages" and "Queries" tabs (Google Sheets, Excel or CSV). Exports from the interface are limited to 1,000 rows per tab: on a site with several thousand pages, filter by directory and export section by section, or use the Search Console API, which connectors such as Looker Studio or spreadsheet add-ons rely on.

To keep data beyond 16 months, there are two options: a monthly export stored in the project folder, or the bulk data export to BigQuery that Search Console has offered since 2023. Like the Google Analytics one, it is not retroactive: it starts on the day it is enabled.

The "Pages" report, in the Indexing section, lists the pages that are indexed and those that are not, with the reason. Export the examples for each status (limited to 1,000 per status): after the migration, they let you check that the old URLs leave the index in favour of the new ones, and that pages previously excluded do not become indexable by mistake. Also note the list of submitted sitemaps and their number of discovered URLs.

The "Links" report shows the pages of your site that receive the most external links, the sites that link to you and the pages most linked internally. The export button offers external links, as a sample or the most recent ones. A URL that receives links must be redirected to its exact equivalent, even if it no longer gets traffic: it is the one that passes on the authority it has earned. See our article on the importance of backlinks during a migration.

Add and verify the new property in Search Console before the launch, then declare the move with the "Change of address" tool once the redirects are active. Keep the old property: it remains the only place to read the old domain's history and to follow its URLs leaving the index.

Pages that receive clicks from Google are the first to redirect: our article where to find the URLs to redirect in Google Search Console explains how to spot them.

All this data has an immediate use: deciding which URLs absolutely must be redirected, and where to. Swan, the redirect plan tool, crawls your current site and its staging version, then matches each old URL with the new ones by semantic proximity. It can also receive URLs from other sources, so you do not forget pages the crawl cannot find:

• Google Search Console, connected directly to your project, which brings in the pages that have impressions in Google;
• the manual import, one URL per line, with their origin: Ahrefs, Majestic, Semrush, server logs, the Search Console links export, or Analytics for a list taken from your Google Analytics 4 exports.

Swan does not connect to Google Analytics: start from your CSV export of landing pages. The reports give paths (/category/page); add the protocol and domain name in front to get full URLs before pasting them. Pages that carry your conversions can be imported with the "Priority URL" origin: they stay in the project even if they match an exclusion pattern.

You then validate the proposed matches, starting with the pages that matter most in your exports. Swan checks the redirects on staging and then in production, and exports the plan as a CSV file, with the origin of each URL, or as redirect rules. That same CSV, matched against your Analytics and Search Console exports, serves as a mapping table to compare each page before and after the migration.

• What to back up before a migration: the complete list
• Backing up the database
• The SEO migration checklist