MMP Migration Checklist: Four Paths Before Singular Renewal
MMP migration checklist compares keeping Singular, outsourcing reporting, switching platforms, or simplifying reports by fit, workload, and renewal timing.
MMP migration checklist: Airbridge publishes this guide to help a team with no Singular dashboard owner choose among four routes.
- Keep Singular and assign someone to learn the reports if the platform still fits your needs.
- Hire an outside operator if the reporting works but your team lacks the time or skill to run it.
- Migrate if the replacement fits your channels, events, reporting, integrations, and data handoff.
- Simplify reporting if you mainly need a short set of recurring decisions rather than another MMP dashboard.
An MMP migration checklist starts with the operating problem: a missing dashboard owner is an operations gap, while a platform change addresses a separate need. If Singular still answers the questions behind your paid acquisition, retain it and add an owner or outsource the work; migrate when a different platform better fits your reporting, implementation, or commercial requirements.
Choose the route before comparing prices or planning app changes.
1. Choose one of four routes
| Route | Fits when | Immediate operating change | Main trade-off to settle before renewal |
|---|---|---|---|
| Keep Singular and train an internal owner | The current setup still answers your acquisition questions, and one teammate can own it | One person becomes responsible for report definitions, recurring checks, and questions from the team | Training and reporting take that person’s time, so agree on a realistic weekly workload |
| Keep Singular and outsource operations | The current setup works, but nobody inside the team can consistently manage it | A contractor or specialist prepares agreed reports and helps maintain the workflow | Set the scope, access, turnaround time, security rules, and monthly cost in writing |
| Migrate to another measurement platform | The current product or commercial terms no longer fit, and a replacement covers the team’s must-have channels and reports | Confirm whether the destination requires an app software development kit (SDK), server-to-server event delivery, campaign setup, or testing, and assign an owner to each required task | Settle the implementation scope, engineering time, and cutover plan before renewal |
| Reduce dashboard reliance | The team makes only a few recurring channel and funnel decisions and can use existing analytics or reports | The team schedules a compact report and assigns someone to review it | Check whether the current reports can answer the team’s cross-channel decisions on the schedule it needs |
Keeping Singular is a reasonable answer when the platform already measures the channels and subscription events you care about. The Singular Help Center lists onboarding, reporting-data, and attribution guides that a new owner can use to learn the existing workflow. Use those materials to train a named owner, then ask your Singular contact which customer support or training options apply to your account and renewal terms.
Give the operator a short brief: which reports arrive each week, what counts as a trial start or paid subscriber, which channel questions need an answer, who approves event or campaign changes, and who can access customer-level data. Your team still needs one internal decision owner, even if a contractor prepares the numbers.
Migration suits a team that wants a different capability, reporting workflow, or contract arrangement, and has the engineering time to implement and test a replacement. An announced renewal date is a contract milestone, while a cutover plan is an implementation schedule. Treat the move as a small product release, with an owner, a test build, partner coordination, and a clear approval point before campaigns or production events change.
A narrower reporting setup can work when the team acts on a handful of numbers, such as attributed installs, trial starts, paid conversions, and revenue by acquisition channel. Keep the report tied to an actual decision, such as pausing a campaign whose trial-to-paid conversion has fallen, and remove low-use dashboard views from the recurring workflow. In Apple’s AdAttributionKit documentation, information Apple cryptographically signs in an attribution postback excludes user- and device-specific data; values from the ad network and advertised app can appear only when they meet Apple’s privacy threshold.
2. Write down what a replacement must preserve
Start with decisions your team made in the last month. A useful scorecard records the report, the decision it supports, the data and settings behind it, and the person who will check it after renewal.
| Requirement | Write down before comparing | Example for a paid subscription app |
|---|---|---|
| Paid channels | Each live channel and campaign type that must continue reporting | Google Ads, Meta, Apple Ads, or TikTok, if your team uses them |
| Events and revenue | The event names, values, and business meaning used in reports or partner postbacks | Trial start, first paid conversion, renewal, cancellation, and purchase revenue |
| Attribution settings | The timing rules for how long after an ad interaction an install can receive credit, which post-install events count, and when a returning user can receive campaign credit | Record the current windows and re-engagement rules exactly |
| Reports | The recurring views that drive a decision, plus the metric definitions | Funnel from attributed install to trial to paid, and revenue by channel |
| Integrations | Each billing, analytics, warehouse, or partner connection the team uses | List the required connectors and who depends on each one |
| Historical data | Reports and exports the team needs for comparisons, finance, or audits | Monthly channel results, event totals, and any available raw or aggregated export |
| Operating ownership | The person responsible for setup, review, and questions | A named internal owner, even when a contractor builds the report |
| Exit and renewal terms | Notice date, cancellation date, post-term access, and export provisions | The clauses and service dates in the signed agreement and order form |
Start with your current report workflow and the source configuration that feeds it. Singular’s migration guide identifies app-SDK or server-to-server event setup, event naming, partner postbacks, and data connectors as configuration work; record the settings and event definitions before changing them. Add trial and paid-subscription stages when those are events your app sends and the reports your team uses.
Keep the metric definition with the number. Compare results with matching attribution settings and report levels so differences between campaign rows remain interpretable.
Decide what data you need to retain before you lose access to the current workspace. Separate three items: report files the team needs to keep, historical data the destination confirms it can import, and access to the current account under the signed contract. Identify the exports your team needs, confirm which the plan and agreement provide, and download a sample while the account is active. Test a sample export by opening it, checking date coverage, and reconciling its totals against the dashboard.
Keep an export manifest with the request date, download date, report name, app and date range, and the person who checked the file. This record lets the team distinguish a complete historical archive from a report that covers only selected apps or dates. Store the manifest beside the file in a team-controlled location.
Use this requirements sheet to compare candidates, then ask each vendor for written answers against the same rows. For any integration tied to subscription revenue, name your current billing platform and the specific events or values it must pass through. Mark each connector as required or optional, and note which reports or data depend on it.
3. Compare migration candidates against the scorecard
| Candidate or route | Evidence relevant to migration | What to prove |
|---|---|---|
| Airbridge | Core setup describes SDK installation, channels, and subscription reporting. | Map the actual event and link inventory; quote any scope beyond Core separately. |
| AppsFlyer | Vendor migration guide covers a cross-vendor move. | Test the replacement before release and identify historical-import requirements. |
| Other shortlisted MMP | Request a cross-vendor migration plan for the source account. | An SDK v4-to-v5 upgrade guide proves a version upgrade, not migration from Singular. |
AppsFlyer’s migration guide recommends finishing migration tasks before releasing the app with its updated SDK, and pausing existing campaigns before a device-ID migration.
AppsFlyer recommends testing the SDK in a pre-production app before releasing the updated production app. The AppsFlyer SDK integration testing guide covers checks for organic and non-organic installs, in-app events, and deep links once integration is complete. The AppsFlyer migration article also points out that media sources differ in whether they allow two MMPs at once, so get a partner-by-partner migration plan instead of assuming a long overlap will work for every channel.
4. Work backward from the renewal date
Work backward from the notice deadline and service-end date in your executed agreement. Start the contract review now, then reserve enough time for the chosen route’s owner, setup, checks, and written cutover decision.
- Find the dates and decision owner. Open the signed Singular agreement and order form. Record the notice deadline, renewal date, cancellation process, service end date, post-term data access, and any minimum term or renewal language. Ask the account contact to confirm these dates in writing. Name one person to own the decision and one person to approve changes to campaigns or app code.
- Capture a baseline while the account is live. Save the recurring dashboards, report definitions, date ranges, attribution settings, event map, link inventory, and integration list. Request the data exports your agreement and plan provide, then verify a sample file against a dashboard total. Keep a dated copy in a team-controlled location with access limited to the people who need it.
- Choose the operating route and budget it. Compare the internal time to retain and train, the defined scope and price for outsourced reporting, the quoted renewal and exit costs, or the implementation workload and recurring price of a replacement. For a narrower setup, write down the handful of reports the founder will actually review and who will maintain each report. Choose the route before the contractual notice date, ahead of the service-end date.
- If migrating, map partners and event ownership. Ask every live ad partner whether it supports dual-MMP testing, meaning two measurement platforms running at once, and how it handles campaign links, event messages, and duplicate events. Dual-MMP support varies by network in Singular’s migration measurement guide. Keep each live partner connection unchanged until that partner’s dual-MMP support and event-handling rules are established.
- Implement and test in a controlled release. Assign the SDK or server-event work to an engineer, and assign campaign links, partner connections, and report configuration to a marketer or operator. Map each existing event to the destination’s event name and value, test install and purchase flows, and check that deep links open the intended app destination. For Airbridge’s documented Meta web-to-app setup, test the campaign’s website destination and tracking link. For AppsFlyer, use its pre-production checks for installs, events, and deep links. Keep the current production flow stable until the replacement passes the checks relevant to your app.
- Compare reports at the right level. Match attribution lookback windows, post-install windows, and re-engagement settings before reading a side-by-side result. Singular advises comparing overall daily aggregate volumes during an MMP migration because attribution waterfalls can differ between providers. Start with aggregate install and event trends, then investigate a specific campaign after confirming the source definitions and settings match.
- Set a short validation window and close the handoff. Agree on the date to stop validation, who signs off, which provider sends event postbacks during the overlap, and which campaigns must be switched in sequence. Singular’s guidance recommends limiting a dual-MMP setup to the time needed for validation and sending in-app events from one MMP to prevent conflicts or duplicates. Once the new reports pass, archive the final exports, record the destination account owner and support path, and update the team’s campaign and event runbook.
If the team retains Singular, use the same baseline and ownership work but replace SDK cutover with a short training plan and a calendar of recurring report reviews. If you outsource, give the contractor the report definitions and access boundaries before the next reporting cycle. If you simplify, agree on the report delivery date and decision thresholds, then close unused dashboard work after stakeholders can get the numbers they need.
Use Singular’s migration measurement guidance as a source-specific starting point for the overlap plan, then confirm the destination and every live partner. Keep this article’s output to an export manifest, event map, link inventory, cutover sequence, and named reporting owner; a fresh vendor price ranking is a separate buying decision.
FAQS
FAQ
Can we run Singular and a replacement MMP at the same time?
Yes for some networks: Singular’s migration measurement guide lists dual-MMP support for Google Ads and Apple Search Ads, partial support for Meta, and one MMP at a time for TikTok for Business.
Does switching MMPs automatically move historical campaign data?
Singular’s migration guide treats historical-data import as optional. Plan the current-account export and any destination import as separate handoff tasks, then confirm each provider’s requirements.
What should we do if renewal is less than a month away?
Choose the lowest-risk route that meets the notice deadline and preserves the reporting the team needs. Confirm contract dates, data access, and export requirements first; if a replacement cannot be implemented and tested before the cutoff, ask Singular about a short renewal or other bridge term while the team completes the migration plan.
How do I know when the new setup is ready to take over?
Approve the cutover after the team has tested the app’s install, subscription-event, link, partner-postback, and reporting flows, and the named owner can reproduce the recurring decisions from the new reports. Compare daily aggregate trends with aligned settings, then record the owner, report schedule, and final handoff date.
Get Started Free
See how these criteria hold up on the real thing.
