Questions

Straight answers

The questions every operator asks after the deal closes — answered the way we'd answer them on a call. No hedging, no vendor spin.

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 lose visibility into the acquired subscriber base, and field dispatch diverges from the office. Stabilize in that order: billing continuity first, then provisioning sync, then support visibility, then field coordination.

How long should dual-run billing last?

As short as possible, as long as necessary — typically one to three billing cycles per migration wave, never open-ended. Dual-run billing should last until two consecutive cycles reconcile within your pre-defined 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.

What's the difference between OSS and BSS in a cable M&A cutover?

OSS (Operations Support Systems) is network-facing: provisioning, plant records, dispatch, network inventory. BSS (Business Support Systems) is customer-facing: billing, CRM, ordering, dunning. In a cutover, BSS decisions drive revenue risk and OSS decisions drive field risk — so decide them separately. The best billing system rarely comes bundled with the best dispatch tool, and pretending otherwise is how vendors win.

When should we retire the legacy billing system post-acquisition?

After two clean parallel billing cycles per subscriber cohort, plus one full dunning cycle so you've seen collections behavior and not just invoice math. Retire by cohort, not by proclamation — and define your rollback criteria before the first cutover, not during it. Keep the legacy system in read-only for one cycle after cutover as the source of truth for disputes.

What's on the COO's post-close systems checklist?

Daily billing reconciliation with a staffed exception queue, a freeze on non-critical system changes, a single incident triage view across both companies, a named integration lead with authority to say no, the system-of-record decision memo (one per domain), a pilot migration wave with validated data, and rollback criteria defined before the first cutover. If any of those are missing, you're not ready to migrate — you're ready to stabilize.

Have a harder question?

Bring it. If we don't know the answer, we'll say so — and we'll know who does.