Tracking parity is a launch-blocking requirement, not a finishing touch. If purchase events, ad attribution, or your indexed URLs are wrong for even a week going into your busiest season, the damage is not cosmetic. It shows up as broken attribution your advertising partner is optimizing against, and as rankings you spent years building that quietly stop resolving. Treat this as part of the build from day one, not a checklist you get to after launch.

Start with an inventory, not a to-do list

Before anyone touches a single tag, find every pixel currently firing on the live site. This is almost never just GA4, Meta, and TikTok, the three you already know about. It is also whatever an app installed silently three years ago, whatever a former agency added and never documented, and whatever your Shopify theme fires by default that nobody remembers turning on. You cannot migrate what you have not inventoried, and guessing at this step is how events go quietly missing after launch.

Four events that have to work before anything else does

Everything else is negotiable on timeline. These four are not, because your advertising spend is actively optimizing against them the moment the new site is live:

1. Purchase, firing with the correct value and currency, every time
2. Add to cart, firing on every path a customer can use to add an item
3. View item, firing on product page load, not on a delayed or conditional trigger
4. Signup, both email and SMS, delivering into the lists your flows already depend on

All four get verified firing correctly before launch, not sampled after. Verifying after launch means finding out from a week of degraded ad performance, which is the exact outcome this whole approach is meant to avoid.

Verify it with the person who will actually use the data

The most reliable way to confirm tracking works is not to assume it and check dashboards later. It is a joint verification session on staging, before cutover, with whoever runs your advertising, watching events fire in real time against the platforms they actually use. They will catch a malformed purchase value or a missing parameter faster than anyone building the site will, because it is their job to notice when the numbers look wrong.

Klaviyo doesn't get to start over

Existing lists, flows, and segments carry over as they are. A replatform is not a reason to rebuild your email program from scratch, and it should never look like one to a subscriber. Consent state migrates with the subscriber, so nobody who opted in under the old site gets re-prompted or, worse, dropped from a flow they were already in.

Consent handling itself needs the same care as the events it gates. If a customer declined tracking on the old site, that choice has to carry forward, not reset to a default the moment the new storefront goes live. Getting this wrong is not just a compliance risk, it is also how you end up with tracking numbers that look complete but are quietly missing a segment of real customers.

URLs are a promise you made to search engines

Every indexed URL represents ranking equity that took time to earn. The default is to preserve URL structure wherever the new architecture allows it. Where a URL has to change, it gets a redirect, mapped one to one, not a blanket redirect to the homepage. Metadata, structured data, sitemap, and robots get configured as part of the build, not patched in afterward.

Then you check the work. A crawl of the old site before launch and a crawl of the new site after cutover, compared directly, is the only way to confirm nothing dropped out of the index without you noticing.

Cutover like it's a production deploy, because it is

By the time cutover happens, none of this should be new information. A full staging environment used throughout the build means the pixel inventory, the four events, and the redirect map have all already been reviewed against a working site, not a slide deck. Cutover itself happens at a low-traffic hour, with a rollback path staged and ready, not assumed to work if needed.

Going live is not the end of the checklist. A monitoring window in the days after launch, watching the same four events and the same crawl comparison, is what catches the failure that only shows up under real traffic instead of a staging test.

This is the same discipline behind targeted fixes as a launch-blocking scope item rather than an afterthought, and it is part of every headless commerce for exactly this reason. If you are weighing whether your current setup can absorb a migration safely, a free teardown is the fastest way to find out before a date is on the calendar.