An ad server migration should move through five gates: map the configuration, validate a representative sandbox workflow, reconcile delivery and money, shift a bounded share of traffic, and retire the previous system only after rollback and reporting obligations are resolved. Assign an owner and a pass condition to each gate before changing production traffic.
This checklist applies to publishers, agencies and platform teams moving campaigns or inventory to a new serving system. It includes Riptide-specific references where they help implementation. It does not assume a universal importer, transferable frequency counters or unchanged partner behavior.
1. Inventory the serving and reporting dependencies
Begin with a list of publishers, apps, placements, advertisers, campaign orders, line items, creatives, audiences, demand connections and deals. Add the less visible dependencies: tags, player integrations, tracking domains, customer credentials, scheduled exports and downstream reporting consumers.
For each item, record its owner, source identifier, destination identifier, migration state and validation evidence. Keep this mapping outside the ad response so operations can trace problems without altering production tracking.
| Migration area | Record before importing | Verify in the destination |
|---|---|---|
| Inventory | Publisher, placement, media and domain relationships | A request resolves to the intended inventory |
| Campaigns | Flights, time zones, remaining commitments and status | Only the intended campaign is eligible |
| Targeting | Audience rules, missing-signal behavior and caps | Positive and negative examples behave as intended |
| Creatives | Assets, formats, approvals and tracking dependencies | The actual player or application renders the ad |
| Demand and deals | Endpoints, seats, terms, timeouts and attachments | Agreed test requests reach eligible demand |
| Measurement | Event definitions, reporting delay and fee basis | Delivery and statement totals can be explained |
Do not copy unfamiliar fields by name alone. Two systems can use the same label for different behavior. Where a setting has no equivalent, make an explicit product decision before activation.
2. Protect active campaign commitments
Schedule the migration around the campaigns you need to preserve. Consider finishing short flights on the current system and starting new flights on the destination. If an active campaign must move, document delivery to date, remaining budget, remaining goal, currency and the exact cutover time.
Keep one accountable owner for each active budget during the transition. If both systems will serve distinct traffic segments, allocate explicit budgets and define how their results will be combined. Do not give both the full remaining commitment and expect independent pacing to coordinate itself.
Decide how existing frequency caps and attribution windows will be handled. Configuration export does not establish that counters, identities or attribution history can transfer. A fresh destination counter can change user exposure even when the numerical cap is identical. Record the chosen transition behavior and test it with synthetic identities where permitted.
For Riptide, the advertiser setup guide covers advertisers, orders, line items and creative readiness. Imported configuration still needs an eligible line item or other demand, with a compatible, ready creative, before it can produce delivery.
3. Validate protocols and rendering in a sandbox
Build a small fixture set from the formats and integration features you actually use. Include a direct campaign, a programmatic connection if required, a no-fill case and an ineligible campaign. Use synthetic data and sandbox endpoints for replay; confirm partner authorization before sending any trial traffic to a buyer.
For OpenRTB connections, agree which fields the supply side sends and which the buyer requires. The OpenRTB 2.6 specification distinguishes required, recommended and optional attributes, and explains why the minimum protocol fields may be insufficient for a business integration. Treat that exchange-specific field agreement as a test input.
Check Riptide’s standards coverage before choosing fixtures. OpenRTB and VAST coverage is partial. A valid response in one format does not demonstrate every version, optional field or player behavior.
Then render the response in the actual application or player. Exercise missing media, unsupported duration, a slow partner, denied consent and no fill. Preserve collected privacy signals through the integration and verify the resulting behavior against the configured policy. Do not fill missing signals with permissive assumptions.
4. Verify events separately from ad selection
A returned ad, a rendered ad and a recorded impression are different observations. Test the complete path before comparing revenue or pacing.
Riptide’s Decision API guide describes successful requests with empty decisions as no fill. It also returns signed impression and click URLs for filled decisions. The beacons guide says to preserve the issued URL and call it when the corresponding event occurs. Do not fire impression URLs simply to check that the endpoint is reachable.
Use a sandbox player or test application to produce real test events. Confirm duplicate handling and test delayed events against the configured delivery window. Riptide documents that events received after that window are recorded but not billed. Establish how this differs from the previous system before treating a report discrepancy as a serving defect.
If you use a read-only serving probe, its successful response only verifies the portion it exercised. Tracking inspection without beacon calls cannot validate counted impressions, frequency-cap updates or settlement.
5. Reconcile a bounded test period
Choose a fixed reporting interval, time zone and currency. Compare requests, filled decisions, rendered impressions, clicks, gross amounts, fees and payable totals using agreed definitions. Allow the documented event and reporting delays to elapse before closing the comparison.
Use a discrepancy log with an owner for every unexplained difference. Separate missing events from delayed events, duplicate suppression, different delivery windows and fee configuration. Compare traffic by placement and format; an aggregate can conceal a broken integration.
For example, if one report shows 1,000 filled decisions and another shows 920 impressions, first check whether 80 decisions never rendered. The numbers are illustrative. They do not establish an acceptable discrepancy or prove that either system is wrong.
Set your tolerances before the trial using campaign commitments and business requirements. There is no universal migration percentage that makes reporting or spend differences acceptable.
6. Shift traffic in controlled stages
Select a small, identifiable cohort you can route back. Define the routing mechanism, traffic ceiling, observation period, reviewer and stop conditions. A staged migration might move one test placement, then a limited group of production placements, then additional formats after each group’s evidence is accepted.
Keep each live ad opportunity assigned to one serving path. If you shadow requests, use a deliberately configured nonbillable evaluation path with partner permission, no duplicate live buying, and no duplicate tracking events. Replaying a production auction into two live systems is not a harmless comparison.
Keep configuration changes controlled during the cutover so you can explain differences. Before increasing traffic, check errors, no-fill reasons, playback failures, event delivery, spend and report freshness for the current cohort.
Prepare domains and certificates before switching URLs. Include cached tags, player configuration and the lifetime of already-issued tracking URLs in the transition plan; traffic routing changes do not erase those dependencies.
7. Rehearse rollback and close the migration
Write the rollback action as an executable operational procedure: who changes routing, which previous configuration is restored, how new campaign activation stops, and how delivery during the transition is reconciled. Test it on the initial cohort.
Define immediate stop conditions for incorrect customer access, broken rendering, unexplained spend or tracking failure. Use your agreed thresholds for other degradations. Keep the necessary prior infrastructure, artifacts and authorized credentials available until the rollback window closes.
After full cutover, allow outstanding events and reporting obligations to complete. Retain the exports required by your agreements and data policies, reconcile the final periods, then revoke obsolete credentials and remove unused integrations. Record the destination configuration and operating owners as the new baseline.
For a Riptide migration, start with the ad server capabilities, campaign setup guide and measurement workflow. Bring the mapping, test matrix and unresolved requirements to a migration discussion before committing to a cutover date.