Migrating analytics and historical data for forecasting

Most of the fear about losing your analytics is misplaced

When someone asks me about moving off a rented platform, the analytics question arrives with real dread. Years of dashboards, heatmaps, conversion funnels and traffic graphs, and the quiet belief that all of it will vanish on cutover day. I understand the worry, but most of it is aimed at the wrong thing.

Here is the honest version. The data that actually forecasts demand and informs decisions is your transactional data: the orders, the customers, the catalogue. That data is yours, it moves cleanly into a custom store, and it is the real forecasting fuel. Most of what people call "our analytics" lives in third party tools, is aggregate or sampled or retention limited, and was never truly portable in the first place. The job is not to migrate all of it. The job is to decide, for each source, what you keep, what you snapshot for the record, and what you stop caring about.

This article is that sorting exercise. It is a spoke of the pillar on what moves and what does not, and it leans on the orders and purchase history spoke, because the order history is where the forecasting fuel actually lives.

Three kinds of data, and how portable each is

Almost everything a shop calls "data" falls into one of three buckets, and the three behave completely differently when you move.

The first is your first party transactional data: orders with their line items and dates, customers and their addresses, products, prices, stock movements, returns. You own it outright. It sits in the platform's database today and it moves into your own database on the new store. This is the bucket that forecasts and decides, and it is the one people worry least about, which is backwards.

The second is third party analytics: web analytics such as Google Analytics 4, plus heatmaps and session recording tools. The reports feel like yours, but the raw event stream behind them is held by the tool, not by your shop, and it is usually aggregate, sampled or retention limited by the time you can reach it. You do not migrate this history. You keep the tool across the move and point it at the new store, and you snapshot the few reports you rely on.

The third is platform native analytics: the dashboards built into Shopify, WooCommerce, Magento or the rest. These are convenience views computed from your transactional data. You do not migrate a dashboard. Once your transactional data is in your own store you rebuild better views on top of it, and you own them.

Kind of data	Examples	Who really holds it	What you can move
First party transactional	Orders, line items, customers, products, prices, stock, returns	You, in the platform database	All of it, into your own database
Third party analytics	GA4, heatmaps, session recordings	The tool vendor	The tool itself, plus report snapshots, not the raw history
Platform native dashboards	Built in sales and traffic reports	The platform	Nothing to migrate, you rebuild the views on owned data

If you keep those three buckets straight, the migration stops being frightening and becomes a list of decisions.

What web analytics actually holds, and what you can take

Google Analytics 4 is the clearest example, because its own documentation is precise about how little of it is really yours to carry.

Start with how long the data lives. On a standard GA4 property you can set event data and user data retention to 2 months or 14 months, and nothing longer. The longer windows of 26, 38 and 50 months exist only on the paid Analytics 360 product.¹ Some data is shorter still: age, gender and interest data is always kept for 2 months whatever you choose, and properties Google classifies as Large or XL are capped at 2 months regardless of the setting.¹ So when you open a GA4 exploration hoping for three years of behaviour to study, the raw user level detail older than 14 months is simply gone.

Then there is sampling. When an exploration or a request covers more events than the quota, GA4 does not count them all. It analyses a subset and scales the result up. The quota for event level queries is 10 million events on a standard property, against up to 1 billion on 360.² A busy shop asking a detailed question about a long period is therefore often reading an estimate, not a count. That is fine for spotting a trend and wrong for feeding a precise model.

The only way the full, unsampled, row by row event stream becomes genuinely yours is the BigQuery export, and even that has limits on the free tier. A standard GA4 property can export up to 1 million events per day in the daily batch export, against up to 20 billion for 360. The streaming export has no volume limit, but Google describes it as best effort, with no completeness guarantee, so it may contain gaps.³ The practical consequence is blunt: if you never set up the BigQuery export, there is no complete raw history sitting anywhere for you to migrate. What GA4 holds is retention limited, sampled when large, and only ever covers data collected after you set the property up.

If you want a reminder of how fragile a rented analytics history is, recall what happened to the previous version of the product. Universal Analytics stopped processing new data on 1 July 2023, and in the week of 1 July 2024 Google removed all access to it and deleted whatever had not been exported, permanently.⁴ Every business that had treated those dashboards as its memory lost that memory on a date Google chose. That is the honest case for snapshotting what you need and owning the data that matters.

You keep the tool, you do not migrate its history

The mental model that saves a lot of grief is this: analytics tools are instruments you re point, not archives you move.

On cutover you keep your GA4 property and you tag the new store with it, so measurement carries on without a gap. You do not, and cannot, pour the old property's history into a new one. GA4 only ever reports on data it collected itself after setup, and there is no supported way to backfill a new property with a previous one's events. Be precise about this with anyone who promises otherwise.

What you do instead is snapshot. Before the move, export the handful of reports you genuinely use, the ones that answer a recurring question, as dated files or into a sheet, and keep them with the project record. A year from now, when someone asks how traffic looked the autumn before the migration, you have an answer that does not depend on a retention window. Everything else, the reports nobody has opened in a year, you let go.

What actually matters for forecasting

Here is the part that turns the fear around. A demand forecast is built almost entirely from your transactional history, not from your web analytics. Good forecasts, as the standard reference on the subject puts it, capture the genuine patterns and relationships in the historical data, and how predictable something is depends on how well you understand the drivers, how much data you have, and how similar the future is to the past.⁵ None of those three depend on heatmaps.

What a forecast needs, concretely, is all first party data you already own:

Order line history with dates, which is the demand series itself, one row per product per order.
Stock and availability history, so you do not mistake a stockout for a fall in demand and forecast the dip forward.
Price and promotion history, so that any estimate of price elasticity or promotional lift is measured against what the price actually was.
Returns, so demand is net of what came back.
A calendar of past events: launches, campaigns, outages, the day the warehouse flooded, so the model can be told which spikes were real and which were one offs.

Every one of those lives in the transactional database and moves with it. The mechanics of carrying it across, and of starting the new order numbers cleanly, belong to the orders and purchase history spoke. Once it is in the new store, the methods in forecasting demand with autocorrelation and seasonality and demand forecasting for ecommerce have everything they need.

What a forecast does not need is every click. You do not need the full event stream to know how many of a product you sold each week. The honest intuition on volume is simply that you need enough clean history to show the pattern, and enough events in each segment you want to forecast separately, before a model earns your trust. I will not invent a magic number here, because the real answer depends on the seasonality and the noise in your series. That exact question has its own article: how much data you actually need.

A migration is the moment to set measurement up properly

Because you are tagging a new store from scratch, a move is the best chance you will get to fix measurement rather than copy its faults forward.

Three things are worth doing at this point. First, tag the new store first party and consent aware, so the data you collect is defensible. Google's consent mode passes a visitor's choices to the tags through settings such as analytics_storage and ad_storage; when analytics consent is denied, GA4 sends cookieless pings and models the gap rather than setting cookies.⁶ You still need a real consent banner in front of it. Second, consider server side tagging, which moves the tags off the browser and onto a server you control, for better data quality and finer privacy controls.⁷ Third, because you now own the store, you can feed a clean copy of the transactional data straight into your own reporting instead of inferring everything from the browser.

This is the same thread that runs through who actually owns your business data: the more of your measurement sits on infrastructure you control, the less of it can be switched off, sampled or deleted by a decision you did not make.

Data warehouse and BI

If the shop already fed a warehouse, BigQuery or similar, that warehouse is yours and it carries. Nothing about the shop migration touches it, beyond repointing the loaders at the new store once it is live.

If the shop never had a warehouse, owning the store makes a clean one straightforward rather than exotic. Your transactional data is in your own database, so a scheduled export into a warehouse, and tidy reporting on top of it, is a configuration job, not a plea to a platform for access it may not grant. You stop renting a view of your own numbers.

The practical path

Put together, the whole analytics migration is five honest steps.

Inventory every data source: each analytics tool, each dashboard, the transactional database, any warehouse, any sheet someone maintains by hand. Name an owner for each.
For each source, decide keep, snapshot or rebuild. Keep the tools you will carry, snapshot the reports you will need as a record, rebuild the dashboards on owned data.
Export the transactional history, handled in the orders and customers spokes, because that is the data that forecasts.
Export report snapshots from the third party tools before the move, dated, into the project record.
Tag the new store, consent aware and ideally server side, and stand up clean reporting directly on your owned data.

The weight of the work is in steps three and five, which are about your own data. The analytics tools, steps two and four, are an afternoon of exports and a decision to let the rest go.

Worked example: Fellbeck Outdoor in Leeds

Fellbeck Outdoor (fellbeckoutdoor.example) is an invented shop in Leeds selling walking boots, waterproofs and camping gear. Priya runs it. It has been on a rented platform for five years and is moving to a custom Solidus store. Every number here is made up to show the method.

Priya starts by listing her data sources and writing a single decision next to each. Her list comes out like this.

Data source	What it really is	Decision	Honest plan
Platform order and customer database	First party transactional data	Keep	Migrate in full into the new store, it is the forecasting fuel
GA4 standard property	Third party web analytics, 14 month retention, sampled on big queries	Keep the tool, snapshot the reports	Tag the new store with the same property, export the five reports she uses, let the rest go
Heatmap and session tool	Third party behavioural tool, aggregate	Keep the tool	Add the script to the new store, nothing to migrate
Platform sales dashboard	A view computed from her own orders	Rebuild	Recreate better on the migrated data, owned
A spreadsheet of promotions by week	Hand kept event calendar	Keep	Import it as the promotion history the forecast needs

The sorting takes her an afternoon. The only genuine loss she finds is the user level detail in GA4 older than 14 months, which was already gone before she started, and which she had never once used for a decision.

The transactional migration, done through the orders spoke, brings across five years of order lines with dates, her stock movements, her price changes and her returns. She adds the promotions spreadsheet as a table of events. For the first time all of it sits in one database she controls.

Six weeks after cutover Priya builds her first demand forecast for the winter boots range. It is built entirely on the migrated order history, corrected for the three weeks last January when the boots were out of stock so the model does not read the stockout as weak demand, and told which past spikes were promotions. It is the first forecast she has trusted, and it uses not a single row from any analytics tool. The thing she had feared losing turned out to be the thing she never needed.

What you stop caring about

A migration is also permission to drop numbers that were only ever noise. Vanity metrics that moved nobody's decision, dashboards built because the platform offered them rather than because anyone asked, funnels nobody acted on. If you cannot name the decision a report changes, it does not need a place in the new store. Owning your reporting means you only build the views that earn their keep.

The honest close

Most of the panic about lost analytics is misplaced. The data that forecasts demand and drives real decisions is your transactional data, the orders, customers and catalogue, and that data moves cleanly into a store you own. The rest is tools you re point and reports you snapshot, not a history you migrate. Keep the three buckets straight, decide keep, snapshot or rebuild for each source, carry the transactional data with care, and you come out of the move with better numbers than you went in with, on infrastructure nobody can switch off.

If the analytics part of a move is the bit that worries you, that worry is usually solvable in an afternoon of sorting. Bring your list of data sources to a free workshop and we will mark each one keep, snapshot or rebuild together, and I will show you the first forecast your own order history can support. The first two weeks of work are on me.

Google, [GA4] Data retention (standard properties keep event and user data for 2 or 14 months, with 26, 38 and 50 months on Analytics 360 only, and age, gender and interest data always 2 months), Analytics Help, 2026, https://support.google.com/analytics/answer/7667196 ↩ ↩²
Google, [GA4] Data sampling (the quota for event level queries is 10 million events for standard properties and up to 1 billion for Analytics 360), Analytics Help, 2026, https://support.google.com/analytics/answer/13331292 ↩
Google, [GA4] BigQuery Export (standard properties limited to 1 million events per day for the daily export, up to 20 billion for 360, while the streaming export has no volume limit but is best effort and may contain gaps), Analytics Help, 2026, https://support.google.com/analytics/answer/9358801 ↩
Google, [UA] Universal Analytics has been replaced by Google Analytics 4 (standard properties stopped processing hits on 1 July 2023, and access was removed with unexported data permanently deleted in the week of 1 July 2024), Analytics Help, 2026, https://support.google.com/analytics/answer/11583528 ↩
Rob J Hyndman and George Athanasopoulos, Forecasting: Principles and Practice (3rd edition), section 1.1 What can be forecast, OTexts, 2021, https://otexts.com/fpp3/what-can-be-forecast.html ↩
Google, [GA4] Consent mode (passes visitor consent to tags through analytics_storage and ad_storage, and when analytics consent is denied GA4 sends cookieless pings and models the gap), Analytics Help, 2026, https://support.google.com/analytics/answer/9976101 ↩
Google, About server side tagging, Google Tag Platform developer documentation, 2026, https://developers.google.com/tag-platform/tag-manager/server-side ↩