Pixel Data

Migrating

Moving to Pixel Data

What to bring across, in what order, and how not to bill anybody twice.

5 min read

The order that works

Nothing here is irreversible and nothing bills a customer of yours. Do it in this order and each step is checkable before the next one matters.

  1. 1Send today's usage firstInstall the agent or post events for one day. Confirm the count on the dashboard matches what your existing system saw. If today is right, history will be.
  2. 2Load your price plansSwitch Kit maps an arbitrary rate card to a plan version. Set effective_from to the date the tariff actually started, not today — that is what makes historical events rate correctly.
  3. 3Backfill your historySwitch Kit → Bring your history. Events are rated by the plan in force at their own timestamp, so a March call is priced at March's rate.
  4. 4Run in parallel for thirty daysUpload the totals your existing system produced each month. We email you a daily report of every account where we disagree, and bill nothing.
  5. 5Switch when the report is boringWhen the differences are all explained, issue your first statement from us. Not before.

Will this bill my customers twice?

No, provided your export uses a stable identifier. Every event imported for your account is recorded permanently, so re-running the same file finds them already present and skips them — the import reports how many it skipped rather than silently doing nothing.

This is a separate, permanent ledger from the seven-day window that catches live retries. A backfill of last March is outside that window by definition, so relying on it would let a re-import through.

The one case where dedup cannot help: an export that generates a fresh identifier every time it runs. If your system does that, leave the identifier column unmapped — we derive one from the row's own content (account, instant, destination, quantity), which is deterministic for the same data.

Backfilled identifiers are also written to the live dedup ledger, so an event you imported and then sent again through the agent is dropped rather than charged twice.

Periods are yours, not UTC's

Statement periods are computed in your tenant timezone. A London July begins at 23:00 UTC on 30 June, so a call at 00:30 on 1 July is on the July statement — which is where your existing system almost certainly put it too.

Set the timezone before you backfill. Changing it afterwards moves the boundaries and will make your parallel-run report disagree for reasons that have nothing to do with rating.