Article partially generated by artificial intelligence.
In our post about painful platform migration we wrote that The Trade Desk – the world’s most powerful independent DSP, processing $12 billion in ad spend annually – missed its own revenue guidance for the first time in eight consecutive years as a public company.
The stock dropped 27% in a single day.
The cause wasn’t a bad product. It wasn’t losing clients. It wasn’t even competition from Amazon, though that narrative made good headlines.
It was a platform migration gone slower than planned.
Their CEO called it “a series of small execution missteps.” Agencies reported bugs causing failed campaign launches, missing audience segments, and broken integrations – some of them during peak holiday ad spend windows, where every missed impression is real money walking out the door.
If The Trade Desk – with 3,900 engineers, $1.3 billion in cash reserves, and years of platform migration runway – couldn’t make it clean, what does that say for everyone else?
It says this: platform migration in AdTech is one of the hardest engineering problems in software. Not because it’s technically exotic. Because of what’s running on it while you’re trying to change it.
Most platform migration war stories come from banking, healthcare, or enterprise SaaS. The patterns are familiar: technical debt accumulates, the new system is specced, the big cutover is planned, things go sideways.
AdTech platform migration has all of those problems and three more that are specific to the industry.
First: the system never stops. A bank can schedule maintenance windows. An e-commerce platform can go down at 3am on a Tuesday. A DSP, SSP, or campaign management platform cannot. Advertisers are running live campaigns. Bids are being placed in 100-millisecond auction windows. A publisher’s inventory is going unsold every second your system isn’t responding. There is no quiet moment to flip the switch of platform migration.
Second: the integrations are a jungle. AdTech platforms don’t exist in isolation. They’re connected – often through brittle, undocumented, or partially-documented APIs – to ad servers, DMPs, CDPs, CRMs, reporting dashboards, verification vendors, bid stream processors, and a dozen other systems. Some of those integrations were built years ago by engineers who no longer work there. Some are undocumented because “everyone just knows how it works.” When you migrate the core platform, every single one of those connections has to be tested, maintained, or rebuilt. The number of potential failure points is not linear – it’s combinatorial.
Third: the users are power users. Media traders who work in DSP interfaces aren’t casual users clicking around to explore. They have muscle memory. They have custom workflows built on top of specific UI behaviors. They have keyboard shortcuts, filter configurations, and campaign templates that took months to build. When you change the interface, you’re not just changing software – you’re invalidating thousands of hours of learned behavior. That’s not a UX problem. That’s a trust problem in platform migration.
The Trade Desk discovered this the hard way when agencies described Kokai, their new AI-powered platform, as harder to use than the system it replaced. Not because Kokai was bad engineering. Because the users had built their entire operational workflows on top of Solimar, and those workflows didn’t transfer automatically.
This is the most common and most dangerous approach in platform migration: build the new system in parallel, test it internally, set a date, flip the switch, and turn off the old system.
It fails because no amount of internal testing replicates the chaos of real production traffic. You will discover integrations that nobody documented. You will find edge cases that only appear at scale. You will find that three enterprise clients built custom automation scripts against the old API that nobody told you about.
The Big Bang cutover guarantees that your users discover your bugs for you – at the worst possible time.
The opposite of the Big Bang: keep both systems running indefinitely, tell users they can switch when they’re ready, and assume it’ll sort itself out.
The Trade Desk did a version of this for nearly two years, supporting both Solimar and Kokai simultaneously. The result: doubled engineering maintenance burden, split product development attention, slower iteration on both platforms, and client confusion about which system to trust for critical campaigns.
Running two systems isn’t a platform migration strategy. It’s a procrastination strategy with a hosting bill.
This is the subtler failure. You rebuild the interface. You add features. The underlying data model is better. The AI is smarter. But you’ve changed the vocabulary.
The old system called it a “placement.” The new system calls it an “ad group.” The old system had a budget cap at the campaign level. The new system handles it differently. The old reporting dashboard showed metrics in a specific order that traders used to build their weekly reports.
These aren’t big changes. They feel like small changes. They are, in aggregate, exhausting – and they erode the trust that took years to build.
Platform migration in B2B software are, at their core, change management problems dressed up as engineering problems.
The engineering is solvable. The change management – keeping enterprise clients informed, trained, and confident throughout a transition that might take 18 months – is where most companies underinvest.
“We’ll have indefinite access to the legacy interface” is a promise that sounds reasonable when made and catastrophic when broken. Clients plan around those promises. They build team training schedules, campaign calendars, and budget allocations based on the assumption that the old system will be there when they need it.
When the promise breaks (even for good technical reasons) it doesn’t feel like an engineering issue to the client. It feels like a breach of trust.
This is the one that haunts every AdTech platform migration modernization project: nobody fully knows what the legacy system does.
Not because it was poorly built. Because it was built over years, by multiple teams, under constant business pressure, with requirements that changed every quarter. The codebase became the documentation. The behaviors nobody can fully explain are the behaviors somebody’s campaign depends on.
Platform migration without understanding the full surface area of the existing system and you will break things you didn’t know you could break.
None of this means platform migration is impossible. It means it requires a different kind of discipline than a greenfield build.
Here is the approach that works- not in theory, but in practice, in real AdTech environments.
Before writing a single line of the new system, invest in understanding the old one. Not just the happy path. The edge cases. The undocumented behaviors. The integrations that exist only in one engineer’s institutional memory.
Map every integration point. Map every API endpoint that external systems depend on. Map every data schema that downstream reports consume. Map every user workflow that power users have built.
This takes longer than anyone wants it to take. It reveals more problems than anyone wants to find. It is non-negotiable in platform migration.
Gartner estimates that up to 40% of IT budgets go to maintaining technical debt. The reason that number is so high is that most organizations don’t know exactly how much they have until they try to replace it.
The strangler fig is a tree that grows around a host tree, gradually replacing it until the host is gone. In software, it means building the new system component by component, routing traffic to the new system incrementally, and decommissioning the old system piece by piece – never all at once.
In AdTech specifically, this means you might run your reporting layer on the new infrastructure while keeping your bidding logic on the old system. Or migrate one channel (display) while keeping another (CTV) on the legacy path until the new system is validated at scale.
The strangler fig approach means you are always running tested, production-proven code. You are never doing a leap of faith.
Whatever your users depend on in the old system must work identically in the new system before they’re asked to switch. Not approximately. Not mostly. Identically.
This means:
Behavioral parity is unglamorous engineering. It is the difference between a migration and a crisis.
Don’t migrate everyone at once. Don’t migrate by account size. Migrate by risk profile.
Start with new clients who have no legacy workflows to protect. Then move to existing clients who are willing early adopters with lower campaign complexity. Then move to mid-tier clients with defined migration windows and dedicated support. Save your most complex, highest-spend clients for last -when you’ve validated the system against real production load and worked out every edge case.
Each cohort is a feedback loop. Each migration teaches you something the next cohort benefits from.
For every component you migrate, before you migrate it, define: what does rollback look like, how long does it take, and what is the trigger that activates it?
Rollback is not a failure. Rollback is proof that you understood your risk and built for it. The migrations that become crises are the ones where rollback wasn’t planned -where the decision to migrate was also, implicitly, the decision to burn the bridge.
In a system processing millions of ad impressions per second, the ability to revert a bad deployment in under five minutes is not a luxury. It is the cost of admission.
Platform migration timelines, deprecation schedules, and breaking changes are not marketing announcements. They are contractual commitments that clients build their operations around.
Every deprecation timeline should be documented, versioned, and communicated with the same rigor as a technical spec. Every breaking change should be announced with migration guides, not just release notes. Every support escalation during migration should be treated as a product signal, not a support ticket.
The clients who trusted your platform enough to build their business on it are the clients most affected by migration problems. They deserve engineering-grade communication, not marketing-grade reassurance.
The Trade Desk’s Q4 2024 miss was $15 million below guidance. The stock reaction wiped out far more in market cap. But the harder-to-quantify cost was the erosion of trust with the agency community -the people who decide, in every RFP, whether TTD stays on the plan or gets replaced by Amazon DSP.
For a mid-market AdTech company, the math is more direct. One enterprise client lost during a platform migration represents not just lost ARR but the opportunity cost of the reference, the case study, the referral network that client would have generated. In a market where sales cycles are long and trust is the primary differentiator, a migration crisis is not a technical problem with a technical fix. It is a commercial problem that takes years to recover from.
Platform migration in AdTech is inevitable. Systems age. Requirements change. The architecture that handled 10 million impressions per day doesn’t handle 10 billion. The consent management that worked under GDPR 1.0 doesn’t work under TCF 2.2. The UI that made sense in 2018 doesn’t serve traders in 2025.
The question is not whether to migrate. The question is whether you are treating it with the discipline it deserves.
Not as an engineering project with a go-live date.
As a change management challenge, a trust preservation exercise, and an archaeological expedition – all happening simultaneously, on a live system, with real campaigns running.
That’s what makes it hard. And that’s exactly the kind of problem we built Sanddev to solve.
Need Holiday Rescue?🌴
👉 AdTechMarTechHotline@sanddev.com
Another TWR which deserves to be published on our blog: this is a “high-fidelity” insight that cuts to the bone of the industry’s lack of ethics. Most agencies use client projects as a paid internship – essentially charging $150/hour for a developer to watch YouTube tutorials on a framework they’ve never used. Not in a […]
Is your software house actually building something? Or just renting people and calling it a strategy?
This week’s roast hits different.
Every migration looks easy on a whiteboard. But always something will go wrong. See 10 the most painful migration and what went wrong.
