Home>Migrations & Replatforming>Custom & Legacy Platforms>Does Migration Erase Historical Attribution Data?
Do we lose years of historical conversion and revenue-attribution data when migrating a custom platform's tracking setup to Shopify?
Historical revenue survives a migration and historical session attribution does not. Imported orders carry the processed date that Shopify's analytic reports use (per shopify.dev, September 2026), so sales history rebuilds. Session-level metrics do not rebuild: Shopify's acquisition reports hold no session data before 1 October 2022, and GA4 standard properties keep event data 14 months at most.
Sort your data into three buckets before you panic about any of it
| Bucket | Lives where | Survives a replatform? |
|---|---|---|
| Order facts: revenue, units, customer, date, discount | In the order record itself | Yes. Imports with the order |
| Order-level attribution: referring site, source channel, UTM values captured at purchase | Fields on the order, settable at import (referringSite, sourceName, per shopify.dev, Sep 2026) | Yes, if the old platform stored them and you map them |
| Session and behavioural data: sessions, bounce, funnel steps, assisted paths | Your analytics platform, not your ecommerce platform | Independent of the migration entirely |
The third bucket is the one people mean when they say they will lose years of data, and it is the one the migration does not touch. GA4, your warehouse and your ad platforms keep whatever they kept. What changes is the site sending them events, which is a continuity problem, not a deletion problem.
Two hard floors that exist whether you migrate or not
- Shopify's own session history starts recently. Shopify's acquisition reports state that historical data for session-based metrics extends back only to 1 October 2022, and that sessions, bounce rates and conversion rates before that date are unavailable (per Shopify Help Center, September 2026).
- GA4 deletes event-level data on a schedule. Standard properties offer 2 months or 14 months of event data retention; Analytics 360 offers up to 50 months. "When data reaches the end of the retention period, it is deleted automatically on a monthly basis" (per Google, September 2026). Crucially, that setting "does not affect standard aggregated reports" and "only affects explorations and funnel reports" (same source).
Read together: much of the multi-year attribution history people fear losing in a migration was already gone, or already reduced to aggregates, before anyone drew a migration plan.
What genuinely breaks at cutover, and what to do about each
- Event schema discontinuity. New theme, new templates, new pixel implementation means event names, parameters and product identifiers change. Year-over-year comparisons break at the seam even though both sides of the seam have data. Fix: freeze and document the event schema before cutover and implement the new site against the frozen schema, not against whatever the new theme emits.
- Identifier changes. Product IDs, variant IDs and SKUs often change in a replatform. Every historical product-level report keyed on the old ID stops joining to the new one. Fix: keep the legacy ID as a metafield on the product and carry it into the analytics payload.
- Attribution model reset in ad platforms. A new domain, a new pixel or a new conversion action restarts the platform's learning. Fix: sequence it, and hold a stable measurement period on either side of the change so you can tell platform reset from performance change.
- Loss of the old platform's own reports. Fix: export before switch-off, not after. This is the only item on the list with a deadline.
When NOT to invest in preserving it
- When nobody has opened the report in a year. The archive costs less than the migration of it.
- When the metric is a rate rather than a count. Rates computed on an old site with old tracking are not comparable to the new ones anyway, so preserving them preserves a false comparison.
- When the fix is a warehouse you do not have. Standing up a data warehouse in the middle of a replatform to save reporting continuity is two projects competing for the same people.
The Deploi point of view
Our own position, from building on Shopify. Separate from the facts above.
- Our take: The order data is not at risk and the schema continuity is. We front-load one deliverable on every replatform that has an analytics dependency: a written event and identifier schema, agreed before build starts, that the new site is implemented against. Everything else on this list is recoverable. A schema decided implicitly by a new theme is not.
- What we’ve seen: Across seven analytics and dataLayer instrumentation engagements, the reporting complaint after a launch is almost never missing history. It is that the new site emits different events with different names, so the two periods will not sit in the same chart.
- Times we’ve shipped this: 7 builds delivered.
- Where we disagree: Migration vendors answer this question by selling more data migration. The honest answer is that the expensive part of the loss is not historical, it is prospective: the comparability of the next twelve months against the last twelve. That is fixed with a schema document and a week of instrumentation discipline, not with a larger import.
- What this page adds: that Shopify's own session metrics have a hard floor at 1 October 2022 and GA4 standard properties retain event data for at most 14 months, so the multi-year attribution history in question frequently does not exist to lose.
Reviewed by Martin Dejnicki, Director of SEO & AI Search. Facts verified 2026-09-14.
Where we worked this out
Our decision records