The way broadband migrations work is changing next year.
The main changes are that they will be slower, and there is much more risk of migrations happening without agreement (slamming).
The existing way means getting a migration authorisation code (MAC) from the losing provider, and giving it to the gaining provider with your order. The gaining provider can validate the MAC, phone number and postcode and place an order in to a carrier to migrate the service over. It takes 5 working days (annoyingly), though with 20CN it seems to be instant now.
The new way is that the customer contacts the gaining provider to take over the line. The only information is telephone number and postcode, so easy for someone else to make the request, no real check that the line actually belongs to the person making the request. The gaining provider places an order with the carrier, and the losing provider gets a notification. The losing provider notifies their customer. The customer can cancel/reject the order. It then takes 10 days now, so slower.
Now, the old way does have rules - the main one is that the losing provider has to provide a MAC within 5 days and not withhold for commercial reasons. This is one of the common issues - ISPs taking too long. The other issue is the losing provider will also use this as a chance for retention which can be annoying.
The new system has rules too. When the losing provider gets notice, they have to advise their customer (by letter normally, but looks like we are OK with email). They are not meant to call and try retention. Of course, you can see that they will just happen to be sending a promotional email or posting or even call at the time... Of course they won't accidentally cancel the migration will they. Of course they will be 100% efficient sending the notice, sending to right place, and sending in time, to avoid slamming. Of course customers will not ignore the notice assuming it is junk, and suffer from slamming...
There are some other quirks which relate to monitoring how this all works and fixing issues if it goes wrong. All resellers have to have a reseller ID (RID) so it is possible to identify who placed orders. But this means defining a reseller. If you simply re-sell a broadband line, then fine. But what of someone selling, say, a point of sale system. They are not selling a phone line or broadband, they are buying these for their use to provide the point of sale system. So who is the customer for the broadband, and is there a reseller? Of course, from our point of view it is complex, as we don't know why our customer is ordering - we have no idea if they are a reseller of the broadband, an end user of it, a customer that is using it as some non re-sell service, or what. We don't know if we should ask for a RID with the order or not. The best we can do is have the option to enter a RID on the order form, but that will confuse people and get mistyped, and so on.
This does not come in until next year, but it has made us ponder some of the logic for migrates already. The process is basically the same for phone lines now, and we often see incorrect take-over requests coming in and contacting the end user to confirm they asked for it. We have issues where our customer may be an IT company (like the point of sale example), and the end user tries to take over a line. They are not the customer for the line, so that has to be rejected. It is hassle. But we have things like our Office::1 package - the phone lines for that are installed by us simply as bearers for the broadband lines which are part of a complete package which offers high availability internet and even includes a mobile dongle as backup. Who is the "customer" for the phone lines there? We don't itemise that on the invoice. Arguably we are the customer, as we buy them solely for the broadband service. Given that nobody else (as far as we know) offers the Office::1 package, do we have to even allow migration of the service? Migrating any part (phone or broadband or mobile) would break the service. What would happen if we ran an IT company that bought the components for Office::1 as the end customer, and used them to provide the Office::1 service to their customer? Who has a right to migrate that? I do get the feeling that OFCOM only thing of the simple cases.
How would I have done it? I suspect I would have made the MAC a fixed (rather than dynamic with 30 day expiry) key that has to be included on every bill. That is easy to police rather than waiting for people to try and get a MAC and finding an ISP is slow. Then we still use a MAC as we do now, and the migrate could be instant even. A new MAC on each change of provider. It avoids annoying retention calls as there is no notice that the MAC is requested/used. It avoids slamming as the bill holder is the only one with the MAC. It would mean almost no change to the existing system. I am pretty sure I suggested this when they consulted. Oh well.