The MMP Migration Checklist to Run Before You Switch

Switching mobile measurement partners is one of the few UA decisions that is genuinely hard to reverse cleanly. Get a creative test wrong and you kill the losing variant a week later. Get an MMP migration wrong and you can lose the ability to compare this quarter's cohorts against last quarter's for months, which is a worse place to be than sticking with a partner nobody is thrilled about.

This piece assumes the decision to switch has already happened, following the criteria this desk laid out in "MMP Selection Criteria in the AdAttributionKit Era". The question now is how to execute the move without breaking the historical record a UA team depends on for every LTV model and budget conversation it will have over the following year.

Why most migration pain is self-inflicted

The technical part of an MMP migration, installing a new SDK and pointing new install postbacks at a new dashboard, is the easy part and the part most teams over-prepare for. What actually causes damage is continuity. A team that runs both MMPs in parallel for too short a window, or defines a core event differently in the new platform than in the old one, ends up with six months of historical data that nobody can compare reliably to the data going forward. The gap stays invisible in migration week and expensive every quarter after, surfacing as an unexplained trend break the first time someone tries to compute a year-over-year cohort comparison.

AdAttributionKit adds a layer most teams did not have to think about during their last migration. It succeeds SKAdNetwork as Apple's privacy-preserving attribution framework, which means a new MMP's conversion value schema, its postback timing windows, its re-engagement handling all need mapping against the old MMP's schema before cutover rather than after. A mismatch here quietly changes how iOS conversions get attributed, for weeks, before anyone spots the discrepancy in reporting.

The migration checklist

Run through this in order rather than in parallel, since several steps depend on the one before it:

• Export and archive full historical raw data from the outgoing MMP, not just dashboard exports, before initiating cutover. Most contracts include a data export window after termination, but it is shorter than teams expect and does not always include raw event-level data by default; confirm the export format in writing before signing a cancellation date.
• Map event definitions field by field between the old and new MMP, particularly for any custom or derived events (first purchase, day-7 active, core-loop milestone). A "purchase" event that includes refunds in one platform and excludes them in another will silently shift every revenue metric across the cutover.
• Rebuild the SKAdNetwork or AdAttributionKit conversion value schema from scratch in the new MMP rather than porting settings, since schema logic (postback timing, hierarchical conversion values, re-engagement windows) is rarely implemented identically across MMPs.
• Run both SDKs in parallel for a minimum of four full weeks, covering at least one full attribution window for your longest post-install event, before decommissioning the old SDK. Two weeks is not enough to catch discrepancies in delayed conversion events.
• Reconcile daily install and revenue counts between the two MMPs during the parallel period, flagging any day where the delta exceeds a defined threshold (5% is a reasonable starting point for install counts) for investigation before it compounds into a trend the team assumes is real.
• Re-point every downstream integration individually: BI dashboards, LTV models, creative testing tools and any automated bidding rules that read MMP data directly. A migration that updates the MMP but leaves an LTV model reading from the old API endpoint produces confidently wrong numbers rather than obviously broken ones, which is the worse failure mode.
• Document the cutover date explicitly in every dashboard and report that spans the transition, so anyone comparing pre- and post-migration cohorts knows to treat the boundary with caution rather than assuming a clean continuous series.

Where teams cut corners and pay for it

The step teams skip most often is the four-week parallel run, usually because a switch is itself driven by cost or contract pressure that makes people want the old platform's bill to stop as soon as possible. That instinct is understandable. It is also wrong. A month of paying two MMPs at once is a rounding error against the cost of an LTV model built on a broken cohort comparison feeding a budget decision three months later.

Second most commonly skipped is field-by-field event mapping, because it is tedious and rarely has an obvious owner sitting between the UA team and the data or analytics team. Assign it to one person before migration begins, with a written sign-off, instead of assuming it happens as a byproduct of the technical SDK integration work.

After the cutover

Once the new MMP is live and the parallel run is complete, keep the old MMP's dashboard access for at least one more full quarter, even once you decommission the SDK. Questions about a specific cohort's original attribution surface after the fact, sometimes during a finance reconciliation or a partner dispute, and losing access to the source system closes off the fastest way to answer them. A migration is not finished when the new SDK is live and the numbers roughly match. It finishes when a UA team can compare a cohort from before the switch to one from after it with the same confidence it had before either MMP changed. Treat that continuity test as the real deadline, not the go-live date. Then the whole thing reads less like a vendor swap and more like what it actually is: protecting a year of historical data from a single migration week.

Related archive reading

These articles provide related context and remain subject to their stated review status.

• The MMP RFP Checklist to Run Before You Switch Vendors
• Migrating 30 live games to a new MMP: Tripledot's Adjust move, and what to ask before you switch