A cutover date set too early becomes a constraint that degrades every other decision. Start with the criteria instead.
Upgrading a BSS to a new major version, or migrating to a new platform, is among the riskiest operations an operator can undertake. Customers, offers, balances, billing history: everything must move with no visible interruption of service.
Start with criteria, not with a date
It is tempting to announce a cutover date at programme launch. It structures the plan and reassures leadership. But a date set before the go/no-go criteria are defined becomes a constraint that pushes teams to cut testing, accept gaps and defer fixes. We recommend the opposite: first define what must be true to cut over, then derive the date.
Rehearsals are the real plan
- Successive dry-run migrations on real volumes, timed, with systematic reconciliation of migrated data.
- A tested rollback plan, not just a written one: the decision to roll back must be possible to make and execute within the planned window.
- A post-cutover service verification (VSR) prepared as a deliverable in its own right, with reference customer journeys.
Governing the cutover night
On the day, the question is no longer technical but about decisions: who decides to continue or stop, based on which indicators, at what time? These decision points, the go / no-go gates, are prepared weeks in advance and rehearsed like everything else.
A successful migration often looks like a non-event. That is exactly the goal.
Information published on this website is provided for information purposes and may change at any time. Publications on this site express general analysis and do not constitute advice tailored to a specific situation.