Migrating Off a Dying DSP Without Disruption

The demand-side platform graveyard is filling up. MediaMath — once a category-defining independent DSP — filed for bankruptcy and shut down. Microsoft is winding down its buy-side DSP, the former Xandr Invest platform, with the lights going off at the end of February 2026. Every consolidation, acquisition, and quiet "strategic review" in this market eventually lands on the same people: the advertisers and operators who built their daily work on top of a platform that is now going away.

When that happens, you inherit a deadline you did not choose. And the instinct — "we'll just export the campaigns and import them into the next platform" — is the most expensive misconception in the entire process. Migrating off a DSP is not lift-and-shift. It is an operational discipline, executed while the business keeps running.

Why "lift and shift" is a myth

Three things make DSP migration hard, and none of them are the data export:

• Object scale, not spend, drives complexity. A migration is measured in advertisers, campaigns, line items, creatives, deals, and targeting rules — not in dollars. A mid-sized local-media operation can carry tens of thousands of advertisers and creatives. At that object count, anything manual becomes fragile.
• Operations cannot pause. The campaigns being migrated are live. Spend is flowing, pacing is running, reports are due. There is no maintenance window in which the business agrees to stop advertising.
• The deadline is external and fixed. A platform sunset is not a date you negotiate. It sets a hard wall, and everything has to be continuous on the other side of it.

Underneath all three is a semantic problem: two platforms rarely model the world the same way. Targeting semantics, pacing behavior, creative handling, deal structures, and reporting definitions differ. "Export/import" silently assumes a one-to-one mapping that does not exist.

The discipline: assess, map, migrate, verify

A migration that survives contact with production follows four phases, not one cutover.

Assess. Inventory the full object graph — advertisers, campaigns, line items, creatives, deals, targeting — plus the workflows, data dependencies, and reporting that surround it. Establish what "still working" must mean the day after the deadline.

Map. Translate legacy objects and semantics into the target platform's model. Decide what to replicate faithfully, what to standardize into templates, and — critically — what cannot map one-to-one, and how that gap will be handled. This is where most of the real thinking happens.

Migrate. Recreate the object graph under load, typically through templated and bulk workflows rather than hand-building. Move creatives, apply targeting, and validate before anything goes live. Where necessary, run old and new in parallel to avoid a single point of failure.

Verify. Reconcile. Does delivery, pacing, spend, and reporting on the new platform match expectations? Surface anomalies early, and keep a rollback path until confidence is earned. A migration is not "done" at cutover; it is done when the numbers reconcile.

Scale, not spend, is the real adversary

This is not theoretical. In one production migration off Xandr, a large US multi-market media operator carried more than 10,000 advertisers and more than 50,000 creatives, with over 5,000 advertisers already active when the migration began. The pressure came not from unusually large spend but from sheer object count: at that scale, manual campaign operations are brittle, and a "dashboard swap" is not a migration plan.

The implication is structural. Migrating that operation meant deploying an operating layer — workflows, monitoring, reporting infrastructure — not just a new place to click buttons.

Automation is a migration tool, not a luxury

At ten thousand advertisers, manual setup is both infeasible and unsafe. In the same migration, a templated console workflow compressed campaign setup from roughly 30 minutes to under a minute: a single guided intake, a creative drop zone, a review checkpoint, then automated advertiser, campaign, line-item, and zip-code-targeting generation.

The lesson is that migration forces a workflow upgrade. A platform move is the natural moment to replace human-heavy setup with controlled automation, because the alternative — recreating tens of thousands of objects by hand against a deadline — is not viable.

You don't really know a platform until you migrate onto it under load

A migration is also a stress test of the destination. Ramp-up exposes infrastructure friction that no amount of pre-planning reveals. In the Xandr migration, the ramp-up period became a production feedback loop: as object scale stressed orchestration, the team tuned AWS usage and infrastructure behavior, reducing infrastructure cost significantly while preserving production-grade service quality.

Latency illustrates why this matters. It was never framed as a formal SLA, but it was operationally critical — degradation would hit win rates, spend, and delivery directly. Treating migration as a one-time cutover misses this entirely; the real engineering happens during the ramp.

Don't migrate one black box into another — own the data

The best migrations fix a deeper problem on the way through: data ownership. Leaving a sunsetting platform only to become dependent on the next vendor's aggregated dashboards repeats the original mistake. The stronger pattern is to use the migration to establish client-owned, event-level data — auctions, impressions, clicks, and conversions streamed into the client's own cloud storage, available as raw and lightly enriched records and joinable on shared identifiers. Migration is the rare moment when changing the plumbing is already on the table; it is the right time to own the pipe.

Common misconceptions

• "Migration is export/import." It ignores semantic mismatch, object scale, and operational continuity.
• "Bigger spend means a harder migration." Object count, not spend, drives the complexity.
• "Cut over on the deadline." Big-bang on the last day is how migrations fail; phase, validate, and reconcile instead.
• "Once migrated, you're done." Ramp-up — optimization and reconciliation — is where the hard work lives.
• "A migration is a technology project." It is an operations project with a technology component.

What good operation looks like

• Treat object scale as the primary risk; template and bulk-process everything repeatable.
• Keep production running; phase the cutover and reconcile continuously rather than trusting a single switch.
• Use the migration to upgrade two things at once — workflow automation and data ownership.
• Budget engineering attention for the ramp-up; expect to optimize the destination under real load.

Open questions

The discipline is young, and several questions are unresolved:

• Is there a credible industry-standard process for migrating off a sunsetting DSP, or is every migration bespoke?
• How much of object mapping can be safely automated, and how much genuinely requires human judgment?
• How should historical performance and learned optimization be preserved across a platform change, rather than reset to zero?

DSPs rarely fail loudly. They sunset on a schedule, handing their customers a date and a choice. Migration treated as export-and-import breaks under scale and time pressure. Treated as a discipline — assess, map, migrate, verify, under production load, with workflow automation and data ownership as the payoff — a forced deadline becomes an infrastructure upgrade.