190,000 Users. 18 Months. Here's How.

Claims about platform quality are easy to make, but migration at scale is where they are tested.

Over the last 18 months, Nebula has migrated 190,000 users onto the CallSwitch One platform. That figure is significant not simply because of its scale, but because of the conditions under which it was achieved: in parallel with active product development, across a highly diverse range of customer configurations, in real-world MSP environments where disruption is commercially unacceptable.

No other provider in the UK market has done this. And the methodology behind it is worth examining in detail, because it reveals what separates a mature migration capability from a learning exercise conducted at customers' expense.

Why Most Migrations Fail

Platform migrations fail in predictable ways. They underestimate configuration complexity, they build processes for straightforward cases and improvise at the edges, and they treat go-live as the destination rather than a milestone. This leaves post-migration issues to accumulate without a structured resolution pathway, and they place the operational burden disproportionately on partners, who are then left managing customer expectations without adequate support.

The consequence is customer churn, damaged partner relationships, and a migration programme that stalls well before it reaches scale.

"There isn't another vendor in the market that's migrated almost 200,000 users within 18 months. That is not a coincidence, it is the result of building a migration process that is engineered for real-world complexity, not optimised for the easy cases."

— Jez Pickering, Head of CX, Nebula

What Made This Scale Achievable

The foundation of Nebula's migration capability is platform ownership. Because we built CallSwitch One ourselves, we were able to build migration tooling that is purpose-designed for our architecture, not retrofitted from generic provisioning tools or adapted from vendor documentation.

That tooling enables automation at a level that is not possible when working with third-party platforms. Configuration transfer, which represents the most time-intensive and error-prone element of most migrations, is automated wherever the customer's existing configuration allows. What would take hours of manual work is reduced to just a few clicks.

"The technical challenge of migrating at this volume is real, but solvable when you own the platform. And as we keep developing, the platform that the 190,000th user migrated onto is materially more capable than the one the first user migrated onto 18 months ago."

— James Lockhart, Head of Product, Nebula

The Pre-Migration Assessment

Scale does not mean speed at the expense of rigour. Every customer migration begins with a structured assessment: mapping the existing configuration, identifying non-standard elements, agreeing a timeline that accounts for the customer's operational constraints, and establishing clear acceptance criteria for go-live.

This investment at the front of the process is what prevents the problems that derail migrations at the back. Complexity that is identified in assessment is planned for, and complexity that is discovered at cutover becomes an incident.

UK-Based Engineering Support Throughout

One of the structural advantages of Nebula's platform is that the engineering team responsible for building it is also the team available to support migrations. There is no separation between the people who understand the platform in depth and the people who are working with partners through the migration process.

This is not a minor operational detail. When something unexpected occurs during a migration, as it will, regardless of how thorough the assessment, UK-based engineering, with direct access to the platform at every level, resolves issues that would take days to escalate and resolve through a global vendor support chain.

The Feedback Loop That Improves the Process

Nebula runs a structured weekly review led by the Head of CX and Head of Product, examining partner feedback and active support tickets to identify patterns. Where a pattern of friction emerges - in migration, in ongoing platform use, or in support interactions, it is addressed at the level of the product, not papered over with workarounds.

The consequence is a migration process, and a platform, that has been continuously refined by 18 months of real-world execution at volume. It is not the same process it was when we started. It is materially better, because every migration has been a source of learning that we have been able to act on.

When assessing migration capability, the signals that matter are rarely in the sales deck. Look for a defined feedback mechanism between support and product, evidence that the process today differs from the process eighteen months ago, and a team that can speak to failure modes as fluently as it can speak to success rates. Those are the markers of a migration function built to last, not just to launch.

Next week: What the migration experience looks like from a partner's perspective, the commercial conversation, the process, and what sits on the other side.