There have certainly been problems porting out of VM, but let's understand it. For one thing a real but small (in terms of numbers) problem can easily get overblown by confirmation bias. A user reports a problem in a forum and this is seized upon as evidence of something much worse. If everyone believed everything posted on these forums they won't touch VM with a barge pole and VM would be bankrupt soon.
We must acknowledge that VM’s VoIP platform is actually more portable than PSTN ever was as VoIP lines are SIP/IMS-based, held in standard UK number portability databases and no longer tied to physical line cards or CMTS regions. So, this reduces technical lock-in but there can still be problems due to factors such as:
- Metadata errors – wrong account details, CLI format, or service address.
- Range-holder mismatches – inherited blocks not correctly linked in provisioning.
- Incomplete portability records – missing flags or incorrect entries in the central database.
- VM back-office bottlenecks – delays or manual interventions in OSS/BSS workflows.
- Failed port-out validation – automated checks reject valid requests if records don’t match.
- Digital Voice re-provisioning overwriting metadata – updates to VoIP provisioning inadvertently reset portability flags.
These problems are ever-present regardless of whether it's BT or VM in charge, but VM has the greater problems due to its inherited blocks and mix of PSTN/VoIP systems which make its metadata more complex.
Having said all of this, most ports do work even though there can be problems. (Bear in mind that OFCOM requires porting to be done and does not allow “blocking” numbers). What I think is wrong is to recommend a blanket port to a SIP provider regardless of what the poster asked for or needs.
