Why traffic migrations go wrong
Automation migrations fail loudly — dead air tells you immediately. Traffic migrations fail quietly: a missing standing order that stops airing, a rotation that ships the wrong copy for three weeks, an invoice that never goes out because the order it belonged to did not survive the load. The failure surfaces a month later as a revenue shortfall or an advertiser dispute, long after everyone stopped watching closely.
The discipline that prevents all of it is the same one accountants use for any ledger conversion: close clean, load once, prove in parallel, cut on a boundary. The rest of this guide is that sentence, expanded.
Step 1 — Export everything, then audit the export
Pull six data sets from the outgoing system, in this order of care:
- Advertisers & agencies — names, billing addresses, terms, tax status, credit limits. Deduplicate now; every duplicate becomes two AR balances later.
- Active and future orders — flights, rates, dayparts, spot lengths, separation and competitive rules. Future-dated and standing orders are the ones migrations forget.
- Copy & rotation instructions — which cart airs for which order, in what rotation, with what start and end dates. Losing rotations means right advertiser, wrong message.
- Open receivables — the aging ledger, exported as close to cutover as possible.
- History you must keep — contracts, credit memos, and as-aired logs for at least the current quarter, for dispute protection.
- Rates & inventory definitions — break structure, avails per hour, rate cards, so the new system prices what the old one priced.
Then audit: row counts per table, total open AR to the penny, and a spot check of ten real advertisers against the old screens. An export nobody audited is a rumor, not data.
Step 2 — Load into the new system and validate before go-live
Load in dependency order — advertisers before orders, orders before copy, copy before logs — and validate each layer before loading the next. The test that matters at this stage is a generated log: have the new system build tomorrow’s log and compare it, spot by spot, against the old system’s log for the same day. Placement, separation, and rotation all prove themselves in that comparison.
Resist the urge to migrate everything. Advertisers with no activity in two years and zero balance belong in an archive export, not in the new system’s advertiser list. Migrating dead data is how a clean new system starts life messy.
Step 3 — The parallel cycle: both systems, one month, reconciled
For one full billing cycle, run both systems against the same reality. The old system remains the system of record — its logs air, its invoices go out. The new system shadows it: same orders, same logs generated, same month-end billing run. Then reconcile three things:
- Daily logs — every spot the new system places, compared against what actually aired.
- Month-end invoices — totals by advertiser, to the dollar. Investigate every variance; each one is a load error you get to fix before it bills anyone.
- AR aging — the new system’s opening balances plus the cycle’s activity must tie to the old system’s closing statement.
When a full cycle reconciles clean, the migration is proven — not before. If it does not reconcile, you have lost nothing: the old system billed the month, and you fix and repeat.
Step 4 — Cut over on a billing boundary
Close the final month completely in the old system: bill it, post payments, print the final aging. Load that closing AR into the new system as opening balances, get a signature from whoever owns the money that the two totals match, and open the new month in the new system alone. Keep the old system readable — not writable — for at least a year of dispute lookups.
The signature step sounds bureaucratic and is not: it is the moment responsibility transfers. Every migration that skips it ends up with an aging report nobody trusts and no way to say when the numbers diverged.
What to look for in the system you are moving to
- Import tooling that expects third-party data — if the vendor cannot load your advertisers, orders and open AR from an export, you are typing them.
- Reconciliation against as-aired reality, not just against the scheduled log — billing what aired is the entire point of traffic.
- A real ledger — accrual billing, AR aging and a general ledger, so the money side survives an audit.
- Standalone operation — a traffic system that only works with its own automation turns a traffic migration into a forklift upgrade of the whole station.
- Network and barter handling — clearance, affidavits and trade are where simple systems quietly give up.
AirWaves Traffic checks all five — it loads from third-party exports, reconciles against the engine’s own as-aired record, carries full AR and general ledger, runs standalone against any automation, and handles network clearance and barter natively. And because it shares a database with the scheduler and the log, the reconciliation step stops being an import ritual and becomes automatic.
Migrate traffic without touching your automation
A traffic migration does not require an automation migration. AirWaves Traffic runs standalone against third-party playout: it exports spot logs your existing automation imports, and reconciles the as-aired data back for billing, affidavits and network clearance. Move the money system first, prove it through a billing cycle, and leave the air chain exactly where it is — whether that is RCS, WideOrbit, Zetta, Simian, ENCO, Rivendell, StationPlaylist or NexGen.
Traffic system migration, answered
Plan for one full billing cycle — typically a calendar month — plus two to three weeks of preparation. The preparation covers exporting and loading advertisers, agencies, orders and copy, then validating the load. The cycle itself is the parallel run: both systems generate logs and invoices for the same month, and you reconcile them before trusting the new one alone. Rushing past the parallel run is where migrations go wrong.
Six sets: advertisers and agencies (with billing addresses and terms), active and future orders (flights, rates, dayparts, separation rules), copy and rotation instructions, the open accounts-receivable ledger, contract and credit history you are required to keep, and at least the current quarter of as-aired logs for dispute protection. Export receivables last, as close to cutover as possible, so the opening balances are current.
On a billing-period boundary, never mid-cycle. Close the final month entirely in the old system — bill it, post it, age it — and open the new month entirely in the new system, with the old system’s closing AR loaded as opening balances. A mid-month cutover means two systems each hold half a month of billing, and reconciling that split is worse than any other part of the project.
Yes, for at least one cycle. The parallel run is what converts “the load looked right” into “the invoices match to the dollar.” Generate logs from both systems daily and compare placements; at month end, run billing in both and compare invoice totals by advertiser. Discrepancies found in parallel cost minutes; the same discrepancies found by an advertiser cost trust.
Cutting over mid-cycle; migrating dead data (five-year-old advertisers with zero balances) instead of archiving it; forgetting future-dated orders and standing orders; losing rotation instructions so the right spot airs with the wrong copy; and skipping the AR balance sign-off, so the new system’s aging never ties back to the old one’s final statement. Every one of these is prevented by the checklist in this guide.
AirWaves Traffic is built to be loaded from third-party exports — advertisers, orders, copy assignments and opening receivables — and to run in parallel against your existing system during the proving cycle. It also runs standalone against third-party automation, so the traffic migration does not force an automation change. Send us a sample export from your current system and we will map it before you commit to anything.
Explore the rest of the platform
Every AirWaves module shares one engine, one database and one login — and every one of them also runs standalone against the automation system you already own.
See AirWaves Traffic running your station
Book a walkthrough with an engineer who has actually run a radio station, or call 1-877-224-1656. No bots, no phone tree.