Lift-and-Shift Is a Myth: The Operational Reality of DSP Migration

There is a sentence that has wrecked more platform migrations than any technical failure: "We'll just export the campaigns and import them into the new platform." It sounds reasonable. The data exists, both systems run campaigns, surely it is a matter of moving rows from one to the other. This is the lift-and-shift myth, and believing it is the single most expensive mistake in a migration — because it assumes the one thing that is never true: that two platforms model the world the same way.

A companion piece covers why migration is suddenly urgent and how to run one as a discipline. This one is narrower: a focused demolition of the myth itself, and an honest account of the operational work the market consistently under-discusses.

The semantic-mismatch problem

The reason export/import fails is not the export and not the import. It is the gap in between. Two DSPs are two different models of advertising. They disagree on:

• Targeting semantics — what a "segment" or a "geo rule" or a "frequency cap" means and how it's evaluated.
• Pacing behavior — how budget is spent over time, which rarely maps one-to-one.
• Creative handling — formats, validation, rotation, and approval states.
• Deal structures — how PMPs, deal IDs, and curated supply are represented.
• Reporting definitions — what "impression," "viewable," "conversion," or "spend" precisely mean.

Export/import silently assumes a one-to-one mapping across all of these. It does not exist. A field that looks identical in two systems can be computed differently underneath, and a strategy that was correct in the source platform can behave differently in the target — not because anything broke, but because the meaning shifted. Migration is, at its core, a translation problem, and translation requires judgment, not a file transfer.

Object scale, not spend, is the adversary

The second myth is that big migrations are about big budgets. They are not. The complexity of a migration is measured in objects: advertisers, campaigns, line items, creatives, deals, and targeting rules — not in dollars.

This is not theoretical. In one production migration off a sunsetting DSP, a large multi-market media operator carried more than 10,000 advertisers and more than 50,000 creatives, with thousands already active when the migration began. The pressure came from sheer object count, not unusually large spend. At that scale, anything manual is fragile, and "swap the dashboard" stops being a plan. Recreating tens of thousands of objects by hand, correctly, against a deadline, while production runs, is not a task a team can muscle through — it requires templated, bulk, validated workflows or it fails.

The work the market doesn't talk about

If migration isn't export/import, what is the actual work? It's the unglamorous middle that vendors rarely put in a pitch:

• Object mapping. Deciding, object class by object class, how source semantics translate to target semantics — what replicates faithfully, what standardizes into templates, and what genuinely cannot map and needs a deliberate workaround.
• Bulk recreation under load. Generating the object graph through templated and automated workflows rather than hand-building, because the scale forbids manual setup.
• Reconciliation. Continuously checking that delivery, pacing, spend, and reporting on the new platform match expectations — catching the places where semantic mismatch produced a silent divergence.
• Rollback. Keeping a path back until confidence is earned, because a migration that can't be reversed is a bet, not a plan.
• Ramp-up tuning. Optimizing the destination under real load, because migration is also a stress test that exposes friction no planning reveals.

None of this appears in "export and import." All of it determines whether the migration succeeds.

Why the myth persists

It's worth asking why a debunked idea keeps selling. Partly because the data really does export cleanly, which makes the hard part — the semantic translation — invisible until it bites. Partly because admitting the truth ("this is a months-long operations project with reconciliation and rollback") is a worse sales story than "seamless one-click migration." And partly because the failures are quiet: a migration that subtly mis-translates pacing doesn't crash, it just under-performs in ways easy to blame on the market. The myth survives because its costs are deferred and diffuse.

Common misconceptions

• "Migration is export/import." It's translation between two different models of advertising; the gap in the middle is the work.
• "Identical-looking fields mean identical behavior." A field can be computed differently underneath; semantics, not labels, decide outcomes.
• "Bigger spend means a harder migration." Object count drives complexity; a modest-spend account with 50,000 creatives is the hard case.
• "You can do it manually if you try hard." At ten-thousand-advertiser scale, manual is fragile and unsafe; templating is mandatory.
• "Once imported, you're done." Reconciliation and ramp-up tuning are where the real effort lives.

What good operation looks like

• Plan around semantic mapping, not data transfer — decide per object class what translates, standardizes, or needs a workaround.
• Treat object scale as the primary risk and template/bulk-process everything repeatable.
• Reconcile continuously against expectations; hunt for silent divergences.
• Keep a rollback path until the numbers prove confidence.
• Budget engineering for the ramp-up, where the destination reveals its friction.

Open questions

• How much of object mapping can be safely automated, and how much needs human judgment?
• Is there a credible industry-standard migration process, or is every move bespoke?
• How should learned optimization and history be carried across a platform change instead of reset to zero?

Lift-and-shift is a comforting story because it makes a hard thing sound easy. But the data was never the problem; the meaning was. Two platforms model advertising differently, the object counts are enormous, and the real labor is translation, reconciliation, and rollback under production load. Call migration what it is — an operations project with a technology component — and you can actually plan it. Call it export/import and you've already planned to fail.