Ad Server Migration With a Parallel Run and Rollback

Budget for a two to five percent gap between the outgoing and the incoming ad server in the first full month, and settle in writing who absorbs it before the switch rather than during the first billing dispute. That gap is not a defect. It is counting methodology, cache behaviour and where each server places the impression event, and it narrows once both sides have a month of overlapping data. Nearly everything else that goes wrong in a migration is preventable, and most of it goes wrong in the direct-sold book. Week one, before anything moves: We inventory what is genuinely live: line items still delivering, contracts running past the cutover date, creative types, and every third-party tag with the macros it depends on. Roughly half of what sits in an ageing ad server is not billing and should be archived rather than recreated. We also tell you in week one if we think the destination is the wrong ad server for your book. That has happened, we said so, and the engagement ended there with the remainder returned. Sequence: Parallel running on a small slice of traffic first, then section by section, never a single overnight switch. Both servers report throughout and we reconcile daily against log-level exports rather than against dashboards, because dashboards round and log files do not. The rollback path stays live until the last section has traded for a full week. What actually breaks: Click and cachebuster macros differ between servers and quietly produce untracked clicks that nobody notices until an advertiser's own reporting arrives. VAST wrappers built around one server's redirect behaviour fail on another, usually only on connected TV, which is the environment nobody tested. Frequency caps reset at cutover, so a campaign capped at three a week can serve six during the crossover unless it is paused deliberately. Historical reporting does not migrate at all: we export it before your contract ends and your access closes, and that deadline is the one people miss. Direct-sold rebuild: Goals, priorities and pacing are re-expressed rather than copied, because a priority number does not mean the same thing in two different servers. Brand safety and exclusivity clauses in a banking or insurance insertion order become labels, competitive exclusions and a QA step that survives the person who set it. Sponsorships are re-modelled against the new server's forecasting before anyone promises delivery again. Timing we refuse: No cutover in the fourth quarter, and none in the closing three weeks of any quarter where you recognise revenue. If your calendar leaves only those windows, the honest answer is to start in January, and we would rather lose the booking than run a migration across your largest trading month. Not included: Contract negotiation or exit terms with your outgoing vendor, though we will draft the technical section of the exit request. Consent platform replacement. Header bidding changes, which stay frozen during a migration so that when a number moves only one thing has changed. That work is scheduled separately afterwards and we say no when asked to bundle it, however tempting the single invoice looks. Who should not book this: Anyone asking for a like-for-like transfer of a thousand line items. We archive what is not billing, and if that is unacceptable a cheaper vendor will move the lot and hand you the same mess in a new interface. Publishers whose ad tags sit in a system nobody can deploy to within a week: fix the deployment path first, because a migration needs several tag changes and at least one of them will be urgent.