How to Migrate to a New Publisher Ad Server: A 7-Step Plan to Protect Revenue

Moving ad servers touches revenue directly, so the migration plan matters more than the destination. Publishers who fail usually lose money to tag errors, missing line item parity, lapsed deal IDs or broken reporting, not to the new platform itself.

This guide is for publishers and ad ops teams moving between platforms in SaaSPodium's Publisher Ad Server Software category, for example from Google Ad Manager to a self-hosted or lighter option, or the reverse. If you are still selecting a platform, start with our publisher ad server comparison or the explainer What Is a Publisher Ad Server?

Two industry standards should be on the checklist from day one. The IAB Tech Lab ads.txt specification lets you declare authorized sellers, and the IAB Europe Transparency and Consent Framework is the common way to pass user consent signals in the EU. Update both for the new platform before traffic moves. Consent also has a legal basis: the EU General Data Protection Regulation and the ePrivacy Directive govern how ad tags may use cookies and personal data.

Step 1: Audit What You Run Today

Start by exporting everything the current ad server does. A complete inventory of ad units, line items, orders, creatives, targeting, deals and reports prevents surprises, because the oldest campaigns are usually the ones nobody remembers configuring.

• Inventory: ad units, placements, sizes, key-values and sections.
• Demand: direct orders, house campaigns, programmatic deals, header bidding and fallback rules.
• Rules: frequency caps, competitive exclusions, geo and device targeting, pacing settings.
• Data: historical delivery, revenue and viewability reports you must retain.
• Integrations: SSPs, DMPs, consent tools, analytics and billing systems.

Step 2: Choose the Target Platform

Pick the platform that matches how you sell. Large publishers with direct and programmatic demand often need a full-featured server; smaller publishers may prefer simpler or self-hosted tools such as Revive Adserver, AdButler or Broadstreet. Developers who want to build their own ad logic may look at Kevel.

Step 3: Map Features and Close the Gaps

No two ad servers model campaigns the same way. Build a feature map that matches each old object to its new equivalent, and flag anything without a direct match so you can decide whether to rebuild it differently or drop it.

• Line item types and priorities to the new platform's equivalents.
• Targeting criteria that do not exist in the new tool.
• Reporting dimensions and metrics you rely on for billing.
• Reservation and guaranteed delivery behavior.
• Creative formats, including video and native.

Step 4: Rebuild Inventory, Tags and Tracking

Rebuild your inventory structure in the new platform before importing any campaigns. Consistent ad unit naming and key-value design pay off for years, so use the migration as a chance to clean up legacy naming instead of copying it.

Then generate new tags and update them through your tag manager or page templates. A staged rollout, by section or by percentage of traffic, limits the blast radius of mistakes. Test viewability, lazy loading, refresh behavior and consent handling on staging pages first.

Step 5: Migrate Demand and Deals

Move demand in order of risk: house ads first, then low-value remnant, then programmatic deals, then guaranteed direct campaigns last. Notify buyers about new deal IDs or seat details in advance so campaigns do not stall.

• Recreate private marketplace deals with new IDs and share them with buyers early.
• Update ads.txt and sellers.json entries so buyers can verify authorized sellers.
• Re-test header bidding wrappers and price floors.
• Run guaranteed campaigns to completion on the old server where possible.

Step 6: Validate With a Parallel Run

A parallel run compares revenue and delivery on both platforms before the full switch. Send a defined share of traffic to the new server and watch for discrepancies in impressions, fill rate, viewability and revenue per thousand sessions.

Impressions_old and Impressions_new are counts for the same placements and period on each platform. Differences of a few percent are common because counting methods vary, but unexplained gaps should be investigated before you scale up.

Step 7: Cut Over and Monitor

Cut over when parallel results are stable, then monitor closely for two weeks. Keep the old server available in read-only mode for reporting and disputes, and record every change made after launch.

• Watch fill rate, eCPM and page speed daily for the first week.
• Review error logs and creative rejections.
• Reconcile invoices with buyers for the transition month.
• Archive historical reports before closing the old account.

Common Migration Mistakes

Most failures come from skipping the audit, forgetting ads.txt updates or moving all demand at once. Plan time for each step, and assign an owner for tags, demand and reporting separately.

• Importing campaigns without cleaning up old line items.
• Forgetting consent signals on the new tags.
• Switching during peak season such as the fourth quarter.
• Discarding historical reports needed for audits.

Frequently Asked Questions

How long does an ad server migration take?
A small site can migrate in two to four weeks. Publishers with many direct campaigns, deals and header bidding usually need two to three months, including a parallel run and buyer communication.

Will I lose revenue during an ad server migration?
A well-run migration limits losses, but a small dip during testing is common. Stage the rollout, keep house ads and fallback demand active, and avoid migrating during peak seasonal periods.

Do I need to update ads.txt when I change ad servers?
Yes, if the new platform or its partners sell your inventory under different seller IDs. Update ads.txt and check sellers.json entries before moving traffic so buyers can verify your authorized sellers.