Tracker Migration Without Losing Conversions

Underneath it, tracker migration without losing conversions is an ordering problem disguised as a technical one. Trackers themselves cooperate - export your offers, set up your campaigns, and the new system works. What refuses to cooperate is time: every click already sent to the old tracker expects its conversion postback at the old address, every network has its own confirmation lag, and every platform acceptance window keeps counting while you move. Cut over in the wrong order and weeks of in-flight conversions arrive at an address nobody is listening to. This guide lays out the migration that loses nothing: the parallel period, postback continuity for old clicks, cutover sequencing, and the verification that closes each stage.

The contracts being preserved here - subid echoes, postback fields, status routing - are the ones documented in the postback-to-CAPI guide; migration is those contracts honored across a move.

Why In-Flight Clicks Are the Real Constraint

A conversion is attributed through the tracker that recorded the click: the network echoes the sub ID that the old tracker issued, to the postback URL the old tracker gave it. That expectation does not expire when you flip a switch - it expires when the funnel cycle of each in-flight click ends: the visitor converts (or not), the network confirms (or rejects), the postback lands (or the window closes on the platform side).

This is why migrations that "just change the links" lose money. From cutover day forward, two populations coexist:

1. New clicks, recorded by the new tracker, expecting the new postback address.
2. In-flight clicks, recorded by the old tracker, still expecting the old postback address - for as long as their confirmations can legally arrive.

Kill the old tracker's postback address on cutover day and population two silently donates its conversions to nobody: the network fires, nothing matches, and the tracker-side symptom is the familiar Click for subid not found row, named exactly so in Keitaro's postback troubleshooting.

The Parallel Period

A migration that loses nothing runs both systems for a while:

1. Set up the new tracker completely - campaigns, offers, postback contracts with the networks, platform integrations - before any traffic moves. A new tracker that receives its first live click before its outgoing postbacks are wired is a conversion shredder.
2. Move new traffic to the new tracker by changing the ad destination links. From this moment, new clicks are born in the new system.
3. Keep the old tracker fully alive - same domain, same postback URL in every network's settings, same platform integrations - for the in-flight population.
4. Let the old tracker wind down naturally. In-flight conversions keep landing as networks confirm them; the report tail grows thinner each day until the only thing left is noise.

Parallel running costs little: two tracker subscriptions and some doubled monitoring. The alternative - a hard cutover - costs every conversion whose confirmation arrives after the old address dies.

Cutover Order: What Changes When

Sequencing rules:

1. Traffic destination links switch first. Ads and rotations point at the new tracker; this is the only step that touches future clicks.
2. Platform integrations split by population. The new tracker's integrations deliver new clicks' conversions; the old tracker's integrations keep delivering in-flight conversions until they dry up.
3. Network postback mappings stay per-tracker. Each network keeps the old postback URL for old offers' in-flight clicks and gets the new URL only for new-tracker offers. Never point a network's postback at the new tracker for offers whose clicks are still in flight in the old one.
4. Platform-side identity stays consistent. If both trackers deliver to the same ad account during the parallel period, nothing platform-side merges their output - Meta's dedup pairs a browser pixel with a server event and does not discard two server events (the dedup rules). The protection is the population split itself: old clicks delivered only by the old tracker, new clicks only by the new one.

During the overlap, watch both books separately. Blending their reports double-counts the migration week; reading them side by side shows the handoff working.

Windows: How Long In-Flight Conversions Can Still Arrive

Three windows bound the migration:

1. The network's confirmation lag - how long after conversion the postback fires. Call-center verticals lag days; instant-approval offers lag minutes.
2. The platform's acceptance window - Meta's Conversions API, for example, accepts event_time up to seven days in the past (using the API), which bounds how late a conversion can still be worth delivering.
3. The network's own reconciliation horizon - some networks re-report status changes long after the initial postback.

Add the longest of these to cutover day - that sum is the earliest honest shutdown date for the old tracker, per the window mechanics. Until then, the old system stays on life support: same domain, same integrations, same postback URLs - receiving, delivering, and slowly emptying.

Closing Each Stage

Verification runs stage by stage:

1. New population: test conversion through the new tracker - postback matched, platform event visible in Test Events (Meta's get started guide documents the visibility windows).
2. In-flight population: the old tracker's postback log keeps landing rows; the Click for subid not found count stays near zero because nothing changed for old clicks.
3. Platform totals: during overlap, watch for doubles - the dedup rules do not merge two server events, so only the strict population split (section above) keeps each conversion counted once (the three-systems guide).
4. Shutdown: only when the old tracker's conversion log has been dry for longer than the longest confirmation lag + acceptance window.

The postback troubleshooting checklist is the daily instrument for both trackers during the parallel period.

Tracker Migration: Frequently Asked Questions

Sources