A new attribution dashboard can be working while the campaigns that depend on it are receiving the wrong events. An existing subscriber can also look like a new install after an SDK change. Neither problem is resolved by seeing roughly similar totals in two reports.
An MMP migration is the transition from one mobile measurement partner to another across app instrumentation, attribution integrations, event delivery, links and reporting. For a live app, authorize that transition only when each dependency has a named owner and observable acceptance evidence. Historical exports, recognition of existing users and uninterrupted campaign signals are separate requirements; none should be inferred from another.
This guide is for app growth and data teams that have a reason to change providers and need to evaluate the handover. If the buying decision is still whether an MMP supplies a missing capability, start with Firebase versus an MMP. Here, the question is whether the proposed migration can preserve the decisions your acquisition program must support.
Write down what must survive the switch
Begin with the decisions that would become unsafe if a feed disappeared or changed meaning. Examples include allocating next week's acquisition budget, evaluating a subscriber cohort, suppressing existing customers from acquisition where permitted, and checking whether a campaign reaches its promised destination.
Create a handover register before approving the release plan. The following is an editorial planning framework, not a platform-prescribed checklist.
Boundary Evidence to retain Acceptance question --- --- --- Business outcome Event definition, value basis and owner Does the new feed represent the same action? Existing users Eligible import coverage and returning-user test Can pre-migration users be distinguished from newly acquired users? Partner signals Sender, destination, mapping and receipt Which provider supplies each live campaign input? Customer journey Link inventory, domain ownership and destination tests Do existing and new links reach the intended experience? Reporting Export samples, definitions and cutover annotation Can an analyst reconstruct the comparison? Exit and recovery Access, retention terms and restoration procedure What can be recovered if acceptance fails?
Make each row specific to an app, operating system, partner and release version. A statement such as “purchase tracking transferred” is too broad. A useful record identifies the exact purchase event, its trigger, currency, value meaning, consent conditions, destination and person who can verify receipt.
Freeze avoidable changes to those definitions during the transition. If a product change cannot wait, version it separately. Otherwise the team will be trying to explain a measurement migration and a business-model change in the same discrepancy.
Separate historical analysis from existing-user recognition
Ask providers to demonstrate what their use of “historical data migration” means. It might describe a device import, selected user attributes, prior campaign fields, or data made available for analysis. Those are different deliverables. Do not assume a complete old reporting environment will be reconstructed in the new product.
Adjust documents importing existing users so their next sessions are not counted as new installs. Its guide warns against submitting the app before that import completes and describes a distinct imported-device network rather than treating imported records as ordinary new acquisition. Adjust migration guide.
Singular describes its optional historical import as an Enterprise feature used to recognize existing devices, with specific identifier requirements and sequencing before the app is live in Singular. That is a provider-specific boundary, not a universal entitlement or a promise that any first-party customer ID will work. Singular migration guide.
Request two separate acceptance demonstrations. First, can a permitted returning-user test be recognized as intended? Second, can the data team reproduce a historical business report from retained exports? Passing the first says little about the second.
Before ending old access, inventory the reports and raw fields your team is entitled to export, their retention limits, documentation and permitted uses. Preserve relevant attribution rules alongside the files. A table of numbers without its time zone, date basis, currency and cohort definition is a weak historical record.
Data transfer also needs an appropriate privacy and security review. The plan should identify which permitted identifiers are necessary, who receives them, how transfer and deletion are controlled, and which users remain outside observable coverage. Missing identifiers are a limitation to record, not a reason to manufacture identity matches.
Two installed SDKs do not authorize two live signal senders
Distinguish three forms of overlap: both SDKs collecting permitted app activity, both providers receiving attribution information, and both providers sending conversion events to an advertising partner. A migration plan must address each separately.
Singular's dual-MMP guidance makes parallel measurement conditional on the app integration and the media source's support. It also recommends controlling in-app event senders to avoid duplication and notes that the old and new systems may not have comparable attribution visibility. Its network table is guidance for that integration context; confirm the exact current partner arrangement before execution. Singular attribution measurement during migration.
Branch separately recommends maintaining SDK overlap for users who have not updated, migrating optimization events and initially reproducing the existing configuration. Those recommendations should inform a provider-specific release plan rather than become a universal overlap duration for every app. Branch MMP migration guide.
For every destination, name the authorized sender, the observing system, the switch condition and the evidence that duplicates are handled. If two senders are proposed, ask the partner and providers to establish the supported deduplication behavior. Do not rely on an undocumented assumption that matching event names prevent duplicate receipt.
Also distinguish collection from optimization. A second provider might be useful for validation without being allowed to supply a live bidding signal. Conversely, a report can look quiet while the campaign still receives events from another integration. Audit the actual paths rather than treating one dashboard as a diagram of the system.
Verify the conversion action that campaigns actually use
On Google Ads, linking a provider, receiving an event and making that conversion action part of bidding are separate checks. Google documents app/provider link IDs and recommends that advertisers retain ownership of their app link IDs when working with agencies. Regenerating a link ID stops the old ID from working, so do not treat regeneration as harmless cleanup. Google Ads provider linking.
Google also documents automatically created and enabled app conversion actions from supported App Attribution Partner feeds. Those actions default to secondary, and that automation does not apply to Firebase conversions. An event appearing in the account therefore does not establish that the intended campaign is optimizing toward it. Automatically enabled app conversion actions.
Record the existing and proposed action IDs, source, event mapping, value definition and saved campaign-goal configuration. Have the media owner and measurement owner review the same record. Avoid enabling an additional purchase action for bidding simply because its label resembles the previous one.
Newly imported third-party app conversion actions begin reporting from the import point described by Google; do not expect the migration to backfill the old action's reporting history into a new action. Keep the transition visible in analysis. Google Ads third-party app conversions.
Other networks need their own current integration instructions and receipt evidence. Do not transplant Google controls, a provider's network table or an old screenshot into another platform's handover. Where account-specific behavior cannot be verified, leave that partner's cutover unaccepted until the relevant support team establishes it.
Give links, cost feeds and privacy measurement separate owners
A campaign link is also a customer-facing route. Inventory paid links, email links, QR codes, web banners and links generated by an API. Record the domain owner, redirect destination, store fallback and intended in-app screen. Some old links can remain in distributed materials after the new campaign setup is complete.
Require a demonstrated continuity plan before changing a domain or ending a link service. Test installed, uninstalled and relevant signed-in states using the team's supported validation process. The deep-linking guide for paid acquisition covers destination acceptance in more detail. Avoid assuming that successful attribution proves the intended screen opened.
Cost collection is another dependency. TikTok documents MMP cost integrations separately and notes that most require ad-account administrator permission; some providers require an additional subscription. Confirm the actual permission and commercial entitlement before promising a complete cost-and-value report. TikTok cost integration with MMPs.
For iOS, inventory the privacy-preserving measurement configuration as its own workstream. Apple's SKAdNetwork documentation describes optional developer copies of winning install-validation postbacks sent to the endpoint configured for the advertised app. Review that endpoint and the receiving infrastructure where used; do not turn a vendor's routing limitation into a claim about all Apple postback recipients. Apple advertised-app configuration.
Assign technical ownership for conversion-value configuration, receipt, interpretation and app-version coverage. Keep consent and permitted-data behavior within the review. Apple holds developers responsible for third-party SDK behavior and requires App Tracking Transparency permission for tracking as Apple defines it. Changing an attribution provider does not create an exception. Apple user privacy and data use.
These are review boundaries, not app-specific implementation instructions or a compliance verdict. The actual SDK version, platform integration, jurisdictions and app behavior determine the technical and legal work required.
Explain discrepancies before approving the new report
Do not make exact dashboard equality the sole acceptance test. Compare like populations first: same app version where possible, operating system, acquisition dates, event maturity, time zone and value basis. Separate event occurrence from attribution credit and cost ingestion.
Consider this fictional example, created only to illustrate reconciliation. The legacy report shows 1,200 installs in a selected window; the new report shows 1,000. Calling the difference a 16.7% tracking loss would be premature.
Suppose an investigation, supported by permitted version and timestamp records, assigns the difference as follows:
Explanation in the fictional investigation Difference --- ---: Activity from app versions without the new integration 120 A date-boundary mismatch corrected by aligning reports 50 Remaining unexplained difference 30 Total initial difference 200
The arithmetic closes, but the migration has not automatically passed. The first 120 require a coverage decision about older app versions. The 50 require a corrected reporting definition. The remaining 30 require investigation or an explicitly accepted limitation tied to the decision at risk.
Those counts are not a benchmark, expected error rate or suggested tolerance. Real categories must be supported, mutually exclusive and reproducible. Do not allocate residual differences to privacy, fraud or “modeling” merely because those explanations sound plausible.
Repeat reconciliation for the event that matters commercially. Install agreement can coexist with missing validated payments, duplicate renewals or inconsistent revenue treatment. Inspect a traceable sample where permitted, then use aggregate comparisons appropriate to the available coverage. When identifiers cannot lawfully or technically be joined, state that limit instead of asserting record-level parity.
Keep migration populations visibly marked in the app marketing dashboard, and compare cohorts at equal maturity. A change in attributed ROAS across providers is not evidence that acquisition performance improved.
Make release acceptance conditional on evidence
Use checkpoints with an owner and a stop condition rather than choosing a generic number of overlap days. The release schedule should account for your update adoption, partner constraints, contractual access and reporting delays.
Before the app release, require accepted event definitions, approved data-transfer scope, provider-confirmed import sequencing and a tested integration in the appropriate development environment. Before changing a partner feed, require that partner's supported transition path and a clear current sender. Before retiring old reporting, require validated exports and reproducible definitions.
For a live production acceptance window, specify what can be observed without making a real purchase or unnecessarily sharing personal data. Technical teams should use supported test modes and controlled, authorized flows. Clearly identify test records so they cannot be interpreted as customers or business results.
Write a recovery procedure before the change. It should distinguish reversible partner settings and link routing from an app binary already installed on a user's device. Restoring a console setting does not recall a released SDK. Identify who can act, which access must remain available, which records must be preserved and what evidence permits resuming affected spend.
A failed partner test can block that partner's switch while unrelated verified reporting continues. Scope the hold to the dependency that failed. Equally, do not keep acquisition running into an unknown optimization feed because a global launch date has already been announced.
Retire the old provider only after the agreed coverage and evidence conditions are met, subject to retention, privacy and contractual obligations. Record residual gaps, ownership of support cases and the historical comparison boundary. A migration is complete when the team can use and maintain the accepted system, with its limitations understood.
What should an agency or provider proposal deliver?
Ask for a plan containing the handover register, app-release dependencies, supported partner sequence, event mapping, link continuity, export scope, acceptance evidence and recovery responsibilities. Have the proposal distinguish included work from dependencies owned by your engineering, data, privacy or platform-support teams.
Evaluate the demonstration, not the promise of a seamless switch. Can the proposed owner show how a current campaign's event travels to its destination? Can the data owner reproduce a pre-migration report? Can the app team show the expected returning-user and destination behavior? Can someone explain a discrepancy without changing definitions until the totals happen to agree?
For established app teams preparing an MMP change, Sharply Labs' mobile app growth practice and paid acquisition and attribution services provide a relevant starting point for a campaign-continuity conversation. Bring a redacted provider and network inventory, app-version coverage, event map, current reporting definitions and the spend decision the migration must preserve.
The initial conversation should produce a prioritized agenda of evidence gaps, responsibilities and proposed validation scope. Deeper analysis, vendor coordination and technical implementation must be separately agreed with the appropriate owners. There is no promise of complete historical transfer, unchanged delivery, platform approval, complete attribution, lower CPI or CPA, or higher ROAS. Contact Sharply Labs to scope an MMP migration readiness review.