Why Most BSS Migrations Die in Cutover — And How to Not Be That Program

There is a specific moment in every large BSS migration program where you can tell whether it's going to land or not. It's not during the architecture phase, not during SIT, not even during UAT. It's about six weeks before go-live, when someone asks: "What's the go/no-go criteria?" — and nobody has a clean answer.

If that moment sounds familiar, you've probably lived through a cutover that didn't go as planned. We have too. And after watching this pattern repeat across Tier-1 operators with programmes worth hundreds of crores, we've distilled it down to three root causes that show up every single time.

"The cutover is not the end of the programme. It's where the programme reveals everything that was quietly wrong for the previous eighteen months."

The Three Structural Failures

• 01
  The cutover plan is built six weeks before go-live, not six months Cutover planning gets treated as a delivery artifact — something you produce near the end — rather than a design constraint that shapes architecture decisions from day one. By the time someone sits down to write the cutover runbook, the system has already been designed in a way that makes a clean cutover structurally difficult. Parallel run periods get shortened. Data reconciliation approaches get improvised. And the business stakeholders who need to sign off on go/no-go have never been told what they're signing off on.
• 02
  Data migration is treated as a task, not a programme On every failed migration we've seen, data migration was assigned to a workstream of three or four people who were also doing other things. No dedicated programme manager. No independent data quality framework. No escalation path when the source data turns out to be far messier than the business case assumed — which it always is. Data migration at scale is a programme in its own right, with its own governance, its own testing cycles, and its own cutover criteria. When it's treated as a task, it becomes the thing that delays everything else.
• 03
  Go/no-go criteria are vague enough that nobody can call it The most insidious failure mode. The criteria exist — they're in a document somewhere — but they're written at a level of abstraction that prevents anyone from making a binary decision. "System performance should be acceptable" is not a go/no-go criterion. "Billing cycle completes within 4 hours for 98% of accounts" is. When the criteria are vague, the decision defaults to politics: whoever has more seniority or more urgency wins, and the technical risks get absorbed by the operations team post-launch.

What Good Looks Like

Programmes that land cleanly share a small number of characteristics that are consistently absent from the ones that don't.

Cutover as a design constraint from day one

The question "how will we cut over?" needs to be asked during architecture design, not after. This changes decisions about data model design, parallel run architecture, fallback procedures, and which legacy capabilities need to be retained during the transition period. Teams that ask this question early build systems that are easier to cut over. Teams that ask it late inherit systems that aren't.

A dedicated data migration programme with its own governance

Separate programme manager. Separate testing cycle. Clear data quality thresholds defined and agreed before extraction begins — not after the first load reveals problems. The source data will always be messier than expected. The question is whether your programme is structured to absorb that reality without derailing everything else.

Binary, measurable go/no-go criteria agreed six months in advance

Every go/no-go criterion should be expressible as a sentence that ends with a specific, measurable outcome. If a room full of people can reasonably disagree about whether the criterion has been met on cutover day, it's not a criterion — it's a discussion topic. Write the criteria. Get them signed. Make them non-negotiable. Then build your testing programme to prove them, not assume them.

If You're in the Middle of a Migration Right Now

Three questions worth asking today, regardless of where you are in the programme lifecycle:

1. Can your cutover plan be executed by someone who wasn't in the room when it was written? If the answer is no, the plan is too dependent on tribal knowledge and too fragile for the actual conditions of a live cutover.

2. Do your go/no-go criteria have owners? Each criterion should have a named individual who is accountable for confirming it has been met — not a team, not a workstream, a person. If it doesn't, the criterion is unlikely to be enforced when it matters.

3. Does your data migration team have an independent escalation path? If data issues have to go through the main programme governance track to get resolved, they will be deprioritised by commercial pressure. Data quality problems that are invisible in governance meetings become visible on cutover day.

These aren't comfortable questions to ask in the middle of a programme. They're more comfortable than explaining a failed cutover to the board.