GA4 Measurement Protocol to Data Manager API Migration: A 10-Step Cutover Playbook

Google has quietly moved the GA4 Measurement Protocol into maintenance mode — no new features, no enhancements, just a slow drift toward irrelevance. If your server-side and offline conversion pipelines still run on /mp/collect, the GA4 Measurement Protocol to Data Manager API migration is now a scheduling problem, not a research project. The Data Manager API went generally available on December 9, 2025, and as of June 15, 2026 the Google Ads API stopped accepting new offline conversion imports — so any new integration you stand up has exactly one supported path.

This is a playbook, not a pep talk. Below is a 10-step cutover with effort estimates for a small marketing data team (one DS/analytics engineer, part-time platform support), the failure modes that will actually bite you, and clear go/no-go criteria so you don’t burn a sprint migrating a pipeline that should just be retired.

Why the GA4 Measurement Protocol to Data Manager API migration can’t wait

Maintenance mode doesn’t mean your existing Measurement Protocol calls break tomorrow. They won’t. But three things are already true: the Measurement Protocol will never get encryption, consent-signal, or match-rate improvements again; one Data Manager API request can fan out to multiple destinations where MP hits a single data stream per request; and the Data Manager API drops the api_secret in favor of OAuth 2.0 with a dedicated datamanager scope. Google has published explicit /mp/collect-to-IngestEventsRequest field-mapping tables — a strong signal of where the roadmap investment is going.

The forcing function is the offline-import cutoff. New offline conversion integrations can no longer use the Google Ads API at all; they must use the Data Manager API. If you’re spinning up any new server-side measurement in 2026, you’re building on Data Manager whether you planned the migration or not. Better to consolidate the old MP pipelines on the same rails than run two stacks.

The 10-step Data Manager API migration plan

Treat this as a sequenced cutover with a parallel-run validation window. The whole thing is roughly a 3–5 week effort for one clean pipeline; multi-destination stacks run longer.

1. Inventory every Measurement Protocol and offline-import pipeline. (2–3 days.) List each /mp/collect caller, every Google Ads offline conversion upload, and every Customer Match job. Capture destination, event type, identifiers sent (email, phone, GCLID), and daily volume. The Data Manager API unifies Customer Match, offline conversions, and GA4 events into one endpoint, so this inventory is also your consolidation map.
2. Stand up a dedicated Google Cloud project. (0.5–1 day.) Create a new project, enable the Data Manager API on it, and keep it separate from your Ads API project — the scopes differ. Note the quota ceiling up front: 100,000 requests/day and 300 requests/minute per project, with up to 10,000 audience members or 2,000 conversion events per request.
3. Configure OAuth 2.0 with the datamanager scope. (1–3 days, plus review lag.) This scope is sensitive, so any app obtaining user credentials must pass Google OAuth verification. Configure the Auth Platform branding and consent screen early — verification can add days of calendar time you don’t control. Service-account flows avoid the consent-screen review; use one for server-to-server pipelines where possible.
4. Map your MP payloads to IngestEventsRequest. (2–4 days.) Use Google’s published mapping tables to translate each /mp/collect field to its Data Manager equivalent. Build a Destination object plus a formatted, hashed, encoded Event. Confirm all first-party identifiers are SHA-256 hashed before they leave your system — the API expects pre-hashed email and phone.
5. Rebuild identifier hashing and normalization. (2–3 days.) Normalize before hashing (lowercase, trim, E.164 for phones) — mismatched normalization is the number-one silent match-rate killer. If you qualify for encrypted matching, wire it in now; MP never offered it, so this is net-new capability, not a like-for-like port.
6. Wire multi-destination fan-out. (1–2 days.) Collapse redundant per-destination callers into single requests that target CM360, SA360, DV360, and GA4 where relevant. Version 1.6 (May 2026) added Google Marketing Platform destinations, so a CM360/SA360/DV360 offline-conversion pipeline is now in scope for the same endpoint.
7. Build a parallel run. (3–5 days, then 2 weeks of clock time.) Send events through both MP and Data Manager for a fixed window. Do not cut over on faith. Compare conversion counts, values, and Customer Match audience sizes side by side.
8. Reconcile match rates and conversion totals. (2–3 days.) Expect small deltas; investigate large ones. Google says that beginning Q3 2026, sending IP addresses with observation timestamps can improve Customer Match rates — so a modest lift on Data Manager is plausible and expected, not a bug. Document a tolerance band before you look at the numbers so you’re not rationalizing after the fact.
9. Cut over one destination at a time. (1 day each.) Migrate lowest-risk, lowest-volume pipelines first. Keep MP live as a fallback for one reporting cycle per destination. Never big-bang a multi-destination stack.
10. Decommission MP and add monitoring. (1–2 days.) Once each destination clears its parallel-run window, retire the MP caller, delete the stale api_secret, and add alerting on request errors, field-level ingestion warnings, and the 100k/day and 300/min quota ceilings.

Common failure modes and how to avoid them

Treating it as a like-for-like port. The Data Manager API is a different data model, not a new URL. Teams that string-replace the endpoint and move on ship broken hashing and empty destinations. Budget for the IngestEventsRequest remodel in step 4.

Under-scoping OAuth review. The datamanager scope is sensitive; the verification queue is not something you can accelerate. Start step 3 on day one, in parallel with the inventory, or it becomes your critical path.

Blind cutover with no parallel run. Skipping steps 7–8 means you discover match-rate regressions in a monthly ROAS review, after budgets already moved. The parallel window is the cheapest insurance in this whole plan.

Normalization drift. Different casing or phone formatting between old and new pipelines silently tanks match rates while every request returns 200 OK. Lock normalization rules in step 5 and diff a sample of raw-to-hashed values.

Ignoring quota math. A high-volume Customer Match refresh can blow past 300 requests/minute if you batch naively. Size batches against the 10,000-member / 2,000-event per-request ceilings before load, not after the 429s.

Decision criteria: migrate now, or wait

Migrate now if: you’re standing up any new offline conversion or server-side pipeline (you have no choice — the Ads API path closed June 15, 2026); you send to multiple Google destinations and want fan-out; you need encrypted matching or the Q3 2026 IP-based match-rate gains; or you’re already consolidating first-party ingestion.

Sequence it, don’t rush, if: your existing MP pipeline is single-destination, low-volume, and stable. Maintenance mode is a freeze, not a shutoff — a stable MP caller can keep running while you migrate higher-value pipelines first. Just don’t build anything new on it.

Skip and retire instead of migrating if: the pipeline feeds a report nobody reads or a conversion action you’re deprecating anyway. Migration effort is only worth it for signals that actually steer budget. Audit before you port.

FAQ

Is the GA4 Measurement Protocol being deprecated in 2026?

Not deprecated — it’s in maintenance mode. Existing /mp/collect calls keep working, but Google has stopped adding features and points all new server-side and offline data work to the Data Manager API. Plan a migration; you don’t need to panic-cut over a stable pipeline this week.

What is the deadline to migrate from Measurement Protocol to the Data Manager API?

There’s no hard shutoff date for the Measurement Protocol itself. The binding date is June 15, 2026: the Google Ads API stopped accepting new offline conversion imports, so any new integration must use the Data Manager API. Existing offline-import integrations continue, but new ones have one path.

Do I need a new Google Cloud project and OAuth setup for the Data Manager API?

Yes. Create a dedicated Google Cloud project, enable the Data Manager API, and configure OAuth 2.0 with the sensitive datamanager scope — which is distinct from Google Ads API scopes and may require passing Google’s OAuth verification. Budget calendar time for that review.

Will migrating to the Data Manager API change my conversion or match numbers?

Expect small deltas and run a parallel window to quantify them. Match rates may rise slightly — from Q3 2026, sending IP addresses with observation timestamps can improve Customer Match — and the API adds encrypted matching the Measurement Protocol never had. Reconcile against a documented tolerance band before cutting over.