How to Migrate From a Legacy Ad Server to Topsort

Most retail media migrations don't start with a technology decision. They start with a frustration.

The sponsored listings program can't scale because the auction logic wasn't built for products. Sellers are asking for reporting that the system can't produce. Engineering is spending more time maintaining workarounds than building new surfaces. The attribution model stops at clicks, and brand advertisers are starting to question the ROAS numbers.

At some point, the calculus shifts from "how do we make this work?" to "how do we move to something built for this?"

This guide is for teams at that inflection point. It covers what to audit before you start, how to phase the migration to reduce risk, and what Topsort's infrastructure makes possible on the other side.

Why Teams Migrate From Legacy Ad Servers

The common thread across most retail media migrations isn't a single breaking point, it's accumulation. Generic ad servers, homegrown systems, and display-first tools can handle early-stage retail media. They stop being sufficient when the program grows to include sponsored listings at scale, seller-funded campaigns, real auction dynamics, purchase attribution, and advertiser self-serve.

The specific triggers vary by team, but the most common ones are:

Auction and relevance limitations. Generic ad servers use line item and priority logic designed for display inventory. That logic doesn't translate cleanly to sponsored listings, where relevance, catalog eligibility, and real-time auction dynamics all have to work together. The result is either poor relevance, poor yield, or both — and a lot of manual intervention to compensate for what the system can't do automatically.

Attribution that stops at clicks. Brand advertisers and marketplace sellers need ROAS, not CTR. When the ad server can't connect ad exposure to purchase events, reporting becomes a liability instead of a selling point. Teams that can't show closed-loop attribution find it hard to grow advertiser spend.

Engineering maintenance burden. Every workaround built on top of a system that wasn't designed for retail media becomes permanent infrastructure. Over time, teams find themselves maintaining a custom commerce layer on top of a publisher tool, which slows down product iteration and creates fragility that only shows up at the worst possible moments.

Inability to expand. The program roadmap calls for display, offsite, in-store, video, and AI optimization. The current stack can handle one surface reasonably well. Adding more requires re-architecting, not iterating.

Operational overhead. Manual campaign setup, manual pacing adjustments, manual reporting pulls. The ad ops team is spending more time on operations than on performance.

Migration shouldn't just solve these problems. It should create a foundation that makes them structurally impossible to recur. That's the difference between a migration that replicates the old system and one that actually improves things. Topsort's engineering approach to zero-downtime, zero-data-loss onboarding is specifically designed for the latter.

Before You Start: What to Audit

The quality of a migration depends almost entirely on the quality of the audit that precedes it. Teams that skip this step end up migrating problems from the old system into the new one.

Map every monetized surface. Search results, category pages, product detail pages, homepage, brand pages, banners, sponsored listings, sponsored brands, native placements, offsite campaigns, in-store screens, email placements. For each one, document the current ad format, placement rules, targeting logic, campaign type, revenue contribution, and technical owner. This becomes your migration scope.

Identify what's working and what isn't. Which placements generate meaningful revenue? Which ones hurt relevance or conversion? Which formats have the strongest advertiser demand? Migration is the right time to retire surfaces that aren't working and redesign the ones that are.

Audit your data flows. Retail media infrastructure needs clean, connected data. Before migrating, map every data dependency: catalog, product IDs, seller and vendor records, category structure, inventory status, search query logs, event tracking, campaign data, budget records, impression and click logs, purchase events, attribution windows, and reporting dimensions. Gaps in any of these create problems that are much harder to fix mid-migration than before it.

Understand your reporting commitments before you touch anything. Advertisers and sellers have dashboards they depend on. Finance has billing records tied to campaign IDs. Account managers have SLAs. Document every external and internal reporting dependency upfront — who needs what, in what format, going back how far. This becomes the spec for Phase 4.

Phase 1: Parallel Infrastructure

Don't cut over the entire stack at once. The first phase is about connecting Topsort's infrastructure alongside your existing system without disrupting live campaigns.

In this phase, you integrate event tracking — impressions, clicks, purchase events — into Topsort in parallel with your current system. You begin catalog sync and validate that product data, seller records, and category mappings are flowing correctly. You set up campaign structures in Topsort and run reporting comparisons to verify that numbers align between the two systems.

This is also a good moment to connect programmatic demand. Topsort's Demand Mediation lets you fill inventory through Criteo and Google Ad Manager from the start, so fill rates stay healthy throughout the transition. For teams migrating from GAM specifically, this means you don't have to choose between moving to better commerce infrastructure and retaining access to Google's demand ecosystem. You can keep both running in parallel until you're ready to make the full switch.

This phase catches data quality issues and attribution discrepancies before they affect live revenue. It also gives engineering confidence in the new system's behavior before anything depends on it.

Phase 2: Limited Placement Launch

Pick one high-value, controllable surface and migrate it first. Sponsored listings on a category page or a secondary search surface are common starting points — high enough intent to generate meaningful data, contained enough to roll back quickly if something goes wrong.

In this phase, Topsort handles the auction and sponsored result delivery for the chosen placement. Your existing system continues to handle everything else. Run the two systems in parallel for long enough to validate that auction quality, fill rates, relevance, and event tracking are all performing as expected before expanding scope.

The Topsort ad server API is designed for this kind of incremental integration — you can migrate one surface at a time without requiring a full architecture cutover upfront.

Phase 3: Auction and Campaign Expansion

Once Phase 2 is validated, expand auction-based decisioning across more inventory. This is where the real capability gap between legacy systems and Topsort's infrastructure becomes visible: real-time auctions that balance bid, relevance, pacing, and eligibility simultaneously across high-traffic surfaces, at sub-5ms p99 latency.

Migrate campaign management workflows in parallel. Move budget setup, targeting configuration, and pacing controls into Topsort's platform. This is also the right phase to introduce AI optimization, which can begin improving yield and ROAS on live traffic as soon as the auction layer is running.

Phase 4: Advertiser Workflows and Reporting

By Phase 4, the infrastructure layer is running on Topsort. This phase migrates the business-facing layer: advertiser self-serve portals, internal reporting dashboards, billing systems, and account management tools.

Plan campaign ID and advertiser account mapping carefully before migrating active campaigns. Sellers and brands should be able to access historical performance data in their new environment without a gap. Finance needs invoice reconciliation that accounts for the transition period. Account managers need to be trained on the new reporting interface before advertisers start asking questions.

Data Genie handles unified reporting and analytics across the migrated program. Topsort's MCP Analytics Server lets internal teams query performance data in natural language rather than building custom BI queries for every report request.

Phase 5: Full Cutover and Optimization

The legacy system is deprecated. All live traffic, campaigns, events, and reporting run through Topsort. Engineering is no longer maintaining the old infrastructure.

This is also where the migration starts generating compounding returns. Surfaces that couldn't support real auctions now can. Attribution that stopped at clicks now reaches purchases. Formats that required manual ad ops can now be managed by sellers directly through self-serve. AI optimization is improving yield and ROAS continuously on live data.

For teams ready to expand further, the same infrastructure supports offsite ads and in-store media without requiring a new vendor or a new integration layer.

Migration Checklist

The phases above cover most of what needs to happen. These are the workstreams that tend to get underweighted and cause problems later:

What Topsort Makes Possible After Migration

The goal of migrating isn't to end up with the same program running on different infrastructure. It's to remove the structural constraints that were limiting what the program could do — real auction dynamics, closed-loop attribution, seller self-serve, AI optimization, and the ability to expand without rebuilding.

Liverpool, one of Mexico's largest retailers, migrated to Topsort to modernize its retail media infrastructure and launch a competitive sponsored listings program. Falabella and Cencosud, two of Latin America's largest retail groups, run their retail media programs on Topsort. These are large, complex programs with real advertiser bases, real auction dynamics, and real ROAS expectations.

Frequently Asked Questions

How long does an ad server migration take?

The timeline depends on the complexity of the current stack, the number of monetized surfaces, the quality of existing data flows, and how much parallel testing is required before cutover. Most teams complete a core integration — auction requests, event tracking, sponsored listing delivery — in a few weeks. Full migrations including advertiser self-serve, reporting dashboards, and catalog sync typically run four to eight weeks. Topsort's phased approach means revenue is not disrupted during the transition.

Can Topsort migrate easily from other platforms (GAM, Criteo, Pentaleap, etc)?

Yes. Topsort can migrate from any legacy or generic ad server, including Google Ad Manager, Kevel, CitrusAd, PromoteIQ, Criteo, custom-built homegrown systems, or any display-first platform that was adapted for retail media. The migration approach is the same regardless of where you're coming from: phased, parallel, and zero-downtime, with fill rates kept healthy throughout the transition.

For teams migrating from GAM or Criteo specifically, Topsort's Google Ad Manager integration and Criteo Demand Mediation Layer mean you don't have to choose between commerce-native auction infrastructure and the other platform’s programmatic demand. You can run both in parallel during the migration and retain GAM for Criteo fill afterward if that makes sense for your program. If your current system is limiting what your retail media program can do, that's the signal. The vendor it happens to be is secondary.

Can Topsort migrate from an in-house ad server?

Yes. Homegrown systems are the most common migration source. They typically have strong product-specific customizations but become increasingly expensive to maintain and hard to scale. Topsort's API-first architecture is designed to map onto existing commerce data models without requiring a full data restructure, which makes homegrown migrations more predictable than they often seem upfront.

What should we migrate first?

Start with a high-value, controllable surface that can validate auction quality and event tracking without putting your entire program at risk. Sponsored listings on a category page or a secondary search surface are the most common starting points. This gives engineering confidence in the new system before expanding scope, and gives finance a clean comparison period before the full cutover.

How do we protect reporting continuity during migration?

Run parallel reporting from both systems during the transition period. Map every campaign ID and advertiser account ID to its equivalent in Topsort before migrating active campaigns. Validate event tracking — impressions, clicks, purchases — against historical baselines before cutting over attribution. Plan historical data access for advertisers and finance before deprecating the legacy system. Reporting continuity is the most common source of migration friction, and the fix is documentation and parallel validation, not speed.

Does migration require downtime?

No. Topsort's infrastructure is designed for zero-downtime migrations. The phased approach means live campaigns continue running on the existing system while Topsort is integrated in parallel. Cutover happens surface by surface, not all at once, which means there's no moment where the entire program goes dark.

Author: Holly Zeng