Guide
Data you must validate before subscriber migration
Direct answer
Validate six data domains before every migration wave: subscriber identity, service address, equipment records, rate codes, open balances and credits, and contract terms. Validate per wave, not once — data drifts. Migrating dirty data just moves the chaos faster.
The six domains
| Domain | What to validate | How |
|---|---|---|
| Subscriber identity | One person, one record — no duplicates across systems | Match on account + address + contact; flag collisions for manual review |
| Service address | Every active service tied to a real, serviceable address | Sample against plant records; flag addresses with no matching node |
| Equipment | Modems, ONTs, set-tops assigned to the right subscriber | Reconcile field inventory against billing equipment records |
| Rate codes | Every subscriber on a valid, current rate — no orphaned promos | List distinct rate codes in use; kill or map the dead ones |
| Balances & credits | Open balances, credits, and payment plans carry over exactly | Trial balance per cohort before and after; investigate every variance |
| Contract terms | Promo expirations, contract end dates, ETF exposure | Flag promos expiring within 90 days of migration — that's a call-center event |
Rules of thumb
- Validate per wave — a one-time validation rots within weeks
- Sample, don't boil the ocean: statistically meaningful samples per cohort, full validation on balances
- Every variance gets a disposition: fix, accept with note, or block the record from the wave
- Keep the legacy system in read-only for one cycle after cutover as the source of truth for disputes
Migrating soon?
Tell us which wave you're on and what the data looks like. We'll tell you what we'd validate first.