Ad server migrations fail for organisational reasons far more often than technical ones — usually because nobody recorded what "better" would look like before starting. This is the sequence that avoids that.
There is never a moment where advertising stops serving. Every stage runs alongside the incumbent, and the previous path stays configured until well after cutover — so rollback is a routing change, not a re-integration.
Do this before anything else. A migration you cannot measure is a migration you cannot defend, and "it feels faster" does not survive a quarterly review.
| Metric | Why it matters |
|---|---|
| Fill rate | The share of avails that earned revenue. Segment it — blended fill hides the problem. |
| CPM | Price achieved. On its own it misleads: a higher CPM at lower fill can mean less money. |
| Revenue per thousand avails | The number that actually matters, because it captures price and fill together. This is the migration's headline metric. |
| Decision latency | Median and 95th percentile. The tail is what viewers experience as a stall. |
| Timeout rate | How often the auction closes before bids return. Often the hidden cause of low fill. |
| Error and slate rate | How often a viewer sees nothing where an ad should be. |
| Discrepancy vs buyers | Your counted impressions against theirs. Establish this now, or you will not know whether the migration changed it. |
Segment every one of these by device platform, content type (live versus on-demand) and geography. Migrations that look neutral in aggregate frequently hide a large regression on one device.
Streaming inventory is strongly seasonal by day of week, and a live sports fixture or a content launch can distort a short window. One week is not a baseline; it is an anecdote.
A copy of live ad requests is sent to the new ad server. Its responses are recorded and discarded — nothing reaches a viewer. Zero risk, real traffic.
This is also the cheapest way to evaluate a vendor before committing. If a prospective ad server will not shadow-test, ask why.
A small share of real traffic — typically starting around five per cent — serves through the new ad server. The rest stays on the incumbent, giving you a live control group.
Decide these thresholds before you start, not while looking at a dashboard:
Ramp in stages — commonly 5, 25, 50, then 100 per cent — pausing at each step long enough for the numbers to settle.
Campaigns with delivery commitments need watching most closely. Confirm pacing against contracted goals at every step.
Re-establish each demand partner and confirm bid rates match what shadow testing predicted. Check your authorisation files list the new seller — buyers filter undeclared supply automatically.
Usually last because it is lowest risk, but confirm sponsorship positions and separation rules transferred intact.
For at least one full billing cycle. Reconciliation questions surface when invoices arrive, and being able to compare is worth more than a tidy configuration.
| Pitfall | Avoid it by |
|---|---|
| No usable baseline | Capturing two weeks segmented by device before any change. The most common failure, and the least excusable. |
| Authorisation files not updated | Adding the new seller to ads.txt and app-ads.txt before ramping, not after fill disappoints. |
| Targeting rules silently dropped | Exporting every rule, cap and block from the incumbent and diffing it against the new configuration. Do not rebuild from memory. |
| Frequency caps reset | Accepting that capping state rarely transfers between servers, and warning stakeholders that early exposure counts will look odd. |
| Comparing across different windows | Only ever comparing against the concurrent control group, never against last month. |
| Live signalling assumed working | Verifying SCTE-35 markers arrive intact on the new path before blaming decisioning for unfilled live breaks. |
| Buyers not told | Notifying demand partners ahead of the ramp. A silent seller change looks like a supply-path anomaly and can get you filtered. |
Integration work itself is short — days, for a standards-based path. The schedule is dominated by measurement windows you should not compress.
| Stage | Typical duration |
|---|---|
| Baseline capture | 2 weeks (can run concurrently with integration work) |
| Integration and scoping | Days for a standards-based path |
| Shadow test | 1–2 weeks |
| Parallel run | 2–4 weeks |
| Staged cutover | 1–2 weeks |
| Old path retained | 1 billing cycle after cutover |
A standards-based integration genuinely can be serving within days, and that claim is about the integration. A responsible migration — with a baseline, a shadow test and a controlled ramp — takes weeks, and the difference is measurement discipline rather than engineering effort. Any vendor promising a fully migrated platform in days is proposing you skip the evidence.
We will mirror a slice of your live inventory and show you latency, fill and yield against your current setup — before you change anything.