Every operator knows the shape of the problem. The OSS/BSS estate has grown for twenty years — point-to-point integrations, custom logic nobody dares touch, systems whose vendor no longer exists. Meanwhile 5G products demand ordering and assurance the estate was never designed for. The tempting answer is a big-bang replacement. The graveyard of those programmes is well populated.
Why big bangs fail here specifically
OSS/BSS isn't a back-office system you can freeze for eighteen months. It touches revenue every second, and its behaviour is defined as much by two decades of undocumented edge cases as by any specification. A wholesale replacement has to reproduce all of that behaviour at once, on day one, under live traffic. That is not a migration; it's a bet.
The incremental playbook
- Wrap first. Put standard, open APIs — TM Forum-style — in front of the legacy estate. New channels and partners integrate against the contract, not the legacy quirks. From that moment, what sits behind the API can change without breaking anyone.
- Carve out by domain. Product catalog, ordering, inventory, assurance — extract one domain at a time to the modern stack, chosen by business pressure, not architectural neatness. 5G product launches usually make catalog and ordering the first candidates.
- Migrate data in slices. Move customer segments or product families in waves, run old and new in parallel, reconcile daily, and keep a tested path back until the numbers prove out.
- Automate the safety net. None of this is survivable without automated regression across the whole estate. Test automation isn't a quality gate at the end; it's the thing that makes weekly change safe in systems that used to change twice a year.
What good looks like
Progress you can measure quarterly: time-to-launch for a new product falling from months to weeks; integration effort for a new partner dropping to days; regression cycles that run overnight instead of over a month. Operators who work this way find the "legacy replacement" finishes almost as a side effect — each slice paid for itself on the way.
The takeaway
- Never bet live revenue on a single cutover.
- APIs first, then domain-by-domain carve-outs driven by business pressure.
- Parallel-run and reconcile every data slice.
- Invest in test automation before you need it — it's the enabler, not the afterthought.
Our telecom teams have delivered exactly these programmes for operators in India and Southeast Asia — see our telecom practice or start a conversation.
