Adjust, Branch and Singular Setup with MMP Migration

We run the outgoing and incoming MMP side by side for one full thirty-day cycle and accept the migration when non-organic install counts agree within three per cent. Above five per cent something is misconfigured, and the point of the parallel run is to find it before you cancel the old contract rather than in the quarter afterwards. One cycle, not two: a permanent dual-MMP setup is a decision nobody made, paid for monthly. The exception nobody plans for: Meta permits one active MMP per app. Meta cannot be parallel-run, so it is a hard cut, scheduled on a day chosen for trading reasons, and excluded from the variance comparison entirely. Google Ads, TikTok and Apple Search Ads each need re-authorisation and each behaves differently on the day it happens. We schedule the self-attributing networks separately from everything else, because bundling them is how a migration turns into a fortnight of nobody trusting any number in the room. Choosing between the three: Branch when the binding problem is web-to-app and deep linking, which is usually a fashion retailer with a large mobile-web catalogue and an app that cannot receive a product URL properly. Singular when the problem sits on the cost side and spend is spread across enough networks that reconciliation is the daily work. Adjust when fraud volume and audience segmentation dominate. We recommend staying put reasonably often. We take no commission, referral fee or revenue share from any of them, which means that recommendation costs us the project rather than earning us one, and it is the only reason to ask us rather than ask them. Link inventory, which is where migrations actually fail: Every live tracking link has to be reissued or redirected: network links, affiliate feeds, influencer bios, partner emails, and the ones nobody has a list of. For food and local services brands there is usually print involved, a QR code on 40,000 menus, vehicle livery, a leaflet drop already committed to a printer. Printed links cannot be re-pointed, so the old attribution endpoint has to keep resolving for the life of the print run, and that requirement belongs in the plan before the SDK work starts rather than after somebody notices installs from restaurant tables going unattributed. SDK coexistence: Two SDKs ship in one build for the parallel window, with install callbacks handled so the same install is not counted twice as a new user, and with a dated removal ticket written at the same time as the integration ticket. If nobody agrees a removal date in advance, the old SDK is still in the binary a year later. We have found three-year-old ones. What you receive: A written selection memo with the reasoning, the migration plan with self-attributing network cut days named, the link inventory, the reconciliation report at the end of the parallel cycle with every variance above three per cent explained by cause, and the sunset checklist with owners against each line. What we refuse: We do not run two MMPs beyond one cycle. We do not migrate inside a peak trading window: no fashion client of ours moves MMP in November, and no food client moves in the fortnight before a national holiday. We do not accept a migration briefed purely as a cost saving with no measurement problem behind it, because the licence difference is generally smaller than the engineering time it consumes and we would rather say that before invoicing than after. We do not write the app-side code. Who this is not for: Single-network apps, where the MMP question is not yet the binding constraint on anything. Teams with no engineering capacity inside the next quarter, since a migration with no developer attached is a document.