The Broadband M&A Systems Cutover: First 90 Days
The press release is out, the bankers are gone, and you're running two of everything. The next ninety days determine whether the deal's economics survive contact with your billing system.
In the first 90 days after a broadband acquisition, the goal isn't one system — it's controlled two systems: billing that reconciles daily, provisioning that matches what's billed, a single incident view, and a vendor-neutral decision on the system of record. Consolidation comes in waves after that.
What breaks first after a broadband acquisition?
Billing breaks first, then everything downstream of it. Dual-run billing without daily reconciliation leaks revenue within weeks. Next: provisioning drifts from billing, support agents can't see the other company's subscribers, and field dispatch diverges from the office. Fix them in that order.
- Billing continuity — missed invoices, duplicate bills, misapplied payments.
- Provisioning ↔ billing sync — services live but unbilled, or billed but never provisioned.
- Customer support — agents blind to half the subscriber base.
- Field ops — dispatch, plant records, and the office stop agreeing.
Days 0–30: Stabilize
Don't migrate anything yet. Make the two systems boring and predictable.
- Freeze non-critical system changes across both stacks
- Stand up daily billing reconciliation with a staffed exception queue
- Map the money path per legacy system: order → provision → bill → collect
- Create a single incident and triage view across both companies
- Protect cash: dunning, payment application, and credits keep running untouched
- Name an integration lead with authority to say no
Days 30–60: Choose the system of record
Choose one system of record per domain — billing, CRM, provisioning, dispatch — not one vendor for everything. Score candidates on billing accuracy under your rate structures, provisioning coverage, field workflow fit, data model and migration cost, and five-year total cost. Write the decision memo and announce it.
| Criterion | What good looks like |
|---|---|
| Billing accuracy | Handles your actual rate structures, bundles, and promo logic without workarounds |
| Provisioning coverage | Covers your plant mix — fiber, coax, fixed wireless — not just the vendor's favorite |
| Field workflow fit | Techs can complete work in it without calling the office |
| Data model & migration cost | Your subscriber data maps cleanly; no heroic ETL |
| Vendor viability & exit cost | You can leave in five years without a ransom |
Days 60–90: Wave-migrate
Move subscribers in cohorts. Every wave has a checklist and a way back.
- Pilot with one market or node — low-complexity subscribers first
- Validate the six data domains before each wave (see our data validation guide)
- Run parallel billing for the cohort and reconcile before cutover
- Brief support with the top ten subscriber-facing changes
- Define rollback criteria in advance — billing error rate, provisioning backlog — and honor them
- Measure: days sales outstanding, billing exceptions, truck rolls per install, support handle time
How long should dual-run billing last?
As short as possible, as long as necessary — typically one to three billing cycles per wave, never open-ended. Dual-run billing should last until two consecutive cycles reconcile within your tolerance, then you cut over that cohort and move to the next. Open-ended dual-run is how operators end up running two billing systems for three years.
More detail: Dual-run billing without losing revenue →
Stabilize-then-wave vs. big-bang
| Stabilize, then wave-migrate | Big-bang cutover | |
|---|---|---|
| Risk | Contained per wave | Every subscriber at once |
| Timeline | Longer calendar, earlier value | Shorter plan, longer recovery |
| Billing | Parallel reconciliation per cohort | One shot, no net |
| Failure mode | Recoverable | Catastrophic |
| Verdict | For operators who like revenue | For operators who like excitement |
Dual-run vs. hard cutover
| Dual-run | Hard cutover | |
|---|---|---|
| How it works | Both systems bill; you compare | One system, one shot |
| Cost | Double ops for a bounded period | Lower ops, higher risk |
| Use when | Billing — which is to say, always | Low-risk domains only, never billing |
Frequently asked
OSS vs. BSS in a cable M&A cutover — what's the difference?
OSS (Operations Support Systems) is network-facing: provisioning, plant records, dispatch. BSS (Business Support Systems) is customer-facing: billing, CRM, ordering. In a cutover, BSS decisions drive revenue risk and OSS decisions drive field risk. Decide them separately — the best billing system rarely comes bundled with the best dispatch tool.
When should we retire the legacy billing system?
After two clean parallel billing cycles per subscriber cohort, plus one full dunning cycle so you see collections behavior, not just invoice accuracy. Retire by cohort, not by proclamation.
What's on the COO's post-close systems checklist?
Daily billing reconciliation, a freeze on non-critical changes, a single incident triage view, a named integration lead, the system-of-record decision memo, a pilot migration wave, and rollback criteria defined before the first cutover.
What data must be validated before subscriber migration?
Six domains: subscriber identity, service address, equipment records, rate codes, open balances and credits, and contract terms. Validate per wave, not once — data drifts. Full breakdown in our data validation guide.
Why do AI pilots stall after an acquisition?
Because the CRM doesn't match billing doesn't match plant, and no model fixes bad joins. Pilots stall on data integration, not algorithms. Fix the system-of-record problem first, then pilot. More in why AI pilots stall.
Want this done for your operation?
Tell us your deal stage, how many stacks are in play, and the risk keeping you up at night. We'll tell you honestly whether we can help.