Knowledge Base

Porting in explained

Started ‎11-09-2012 by
Modified ‎01-07-2019 by

The purpose of this article is to explain in some detail the process of transferring a mobile number into giffgaff from another network. This process is commonly known as porting in.
This article is not intended for the majority of people that want to bring their number to giffgaff, it is a much more technical document describing the process behind number porting. If you are simply wanting to bring your existing phone number into giffgaff you should refer to this article instead.

More Information


Mobile Network Operator. An MNO is a company that has invested billions of pounds to create a physical network (phone masts etc.) to carry provide mobile services like calls texts and data to customers. O2 is an MNO.


Mobile Virtual Network Operator. An MVNO is a company that does not own a physical network itself, but instead runs a mobile service (calls, texts and data) by renting the physical network of an MNO - hence their network is 'virtual'. giffgaff is an MVNO that rents the network from O2-UK.


Mobile Virtual Network Enabler. An MVNE is a company that provides technology and services, e.g. network connectivity and billing, to MVNOs that enable them to run their operations.


Mobile Number Portability system. MNP is the system that manages all ports between all UK networks. The MNP is independent of all MNOs.


The independent regulator that sets the rules for all mobile service providers in the UK OFCOM has made several reviews of porting in the UK and issues several regulations that affect both port ins and port outs.


Port Authorisation Code. This is a number generated by the donor network that allows the customer to transfer their keep number to another network. 


Service Termination Authorisation Code. This is a number generated by the donor network that allows the customer to cancel the old number and phone service. They will get a new number from the new provider.

Keep number:

This is the mobile number that you want to keep. In the example of porting in it is the number that you want to bring into giffgaff from your other network.

Donor network:

The network (it may be either an MNO or an MVNO) that currently has your keep number.

Recipient network:

The network that you want to bring your keep number to. In this case giffgaff.

  • MNP: Does not operate on weekends and Bank Holidays. This means that you cannot port in to any UK network on those days.
  • MNP: Controls the date of the port in, not the donor or recipient network. When a 'port in' request is registered the MNP tells both the donor and recipient network when the port in will happen. Port in dates can be manually changed by the recipient network to be later than the MNP date to accommodate the customers' wishes but they cannot be brought forward.
  • Porting in essentially requires 2 things:
    • The donor network must release the keep number and pass it to the recipient network.
    • The recipient network must provision the keep number. OFCOM set the rules on how long this can take. They stipulate that the time from MNP accepting the port in request to the successful provision of the keep number on the recipient network should be 2 working days.
  • On the day of port in you should allow 24 hours for the port to complete. All UK networks advise their customers of this. The reason is to do with the OFCOM regulations and with network working hours. OFCOM state that the donor network has until 3.00pm on the day of port to release the number. And until this happens the port in process cannot begin. This then only gives the recipient network 2 or 3 working hours to receive and provision the keep number. Inevitably this is sometimes not long enough given the complexity of the tasks involved, the volume of ports in question, and the possibilities for error. For instance, the donor network may not correctly release the keep number. This means some port ins on all UK networks will run into the next working day.

Here is the happy path for a port in to the giffgaff network.

  • The Member contacts their donor network to request a PAC.
  • The Member gives their PAC to giffgaff via the port in form, which also requires the member to complete other details needed by MNP.
  • giffgaff Member Services agents process the form completed by the member and transfer the details into the MNP.
  • MNP accepts the Port in request and returns a Port in date to giffgaff.
  • giffgaff communicate the Port in date to the member.
  • At 3.00pm on the day before the Port in date giffgaff Member Services agents enter the MNP system and lock all keep numbers that are due to port the following day. This confirms the port with the donor network and means the keep number cannot be used by any other network except giffgaff.
  • At the same time, a file is sent to the MVNE which confirms the details of all members whose keep numbers have been locked for port in the next day.
  • On the day of port the donor network release the keep number from their network and sends confirmation of this to the MVNE. Note that each network has until 3.00pm to do this. On a typical day, giffgaff will be expecting a dozen networks to release numbers; that each network will do this at different times; and that each network will have multiple numbers to release, so will batch them up and send them only when all are released.
  • The MVNE processes the files of released keep numbers, matching them with the file sent the previous day from the Member Services agents so that each keep number is associated with the correct Members account. What the MVNE does is:

    • Disconnect the members temporary giffgaff number from the giffgaff network.
    • Connect the members to keep number to the giffgaff network.
    • Ensure the members account details (name address etc.) are associated with the keep number.
    • Ensure the member's product details (goodybag etc.) are associated with the keep number.
    • Ensure the members billing information (current credit balance etc.) are associated with the keep number.

Note that each of these actions requires the MVNE technology to link to different systems in the network architecture. Note also that the MVNE will also batch these processes in relation to when the keep numbers are released by the donor networks.

  • When this process is complete, the MVNE sends a confirmation file to the Member Services agents and to a team that manages the giffgaff website. At this point, the member should have a working service using their keep number on the giffgaff network.

  • The website team update the back end of the website so that the details in My giffgaff now display the new keep number. Note that this is also a batch process and takes a few hours to complete depending on how many files need updating.

It should now be clear why this process can take 24 hours for any network to complete a port (not just giffgaff), even under perfect conditions. It is simply because the process relies on humans to run, process, send and receive files and the humans involved do not work 24/7. They work typically from 9.00am to 5.00pm, and when they go home the process stops.

The most common example is that the keep numbers are not released by the donor network until late in the working day. The file then may take two or three hours or more to be transferred, opened, checked, loaded, and processed. If that cannot be completed it will be finished at the start of the next working day.

This is of course highly frustrating for members who may be without service during this time. But it is a problem with the system itself and not with giffgaff and all UK networks experience this.

The cost of maintaining all the staff needed out of hours, to handle the small % of ports that this happens to is prohibitively expensive and not something that any network would provide let alone a small, low-cost network like giffgaff.

The only way around this is for the industry as a whole to move to a different, more automated porting system as is the case in other parts of the world such as New Zealand.

But as you can imagine this is a complicated task requiring all UK network operators to agree, as well as infrastructure development and a new regulatory framework. Talks and plans are underway but it won't be anytime soon that this happens.

It is logically possible for faults to occur at each of the stages outlined above. And below I have listed a few examples. This list is not exhaustive but is intended to demonstrate the range of things that CAN go wrong and give some idea of how difficult it can be to work out exactly what has gone wrong in any particular case. Some of these issues are much more likely and happen more frequently than others. Many of these have never happened.

  • The donor network may drag their heels in issuing the PAC, or they may issue an incorrect PAC.
  • The member may put the PAC in incorrectly in the giffgaff form; or may get some of the other information wrong, or omit things. The form may be filled correctly but not make it to an agent if there is a fault in giffgaff's website and form-handling process.
  • The giffgaff agent may incorrectly transfer the PAC and other details into MNP.
  • The MNP system may itself be offline or unable to accept the Port request. It may not return a date to giffgaff.
  • giffgaff may fail to update the member with the Port in date.
  • giffgaff agents may fail to process the lock file, or process the wrong lock file, or process an incomplete lock file. MNP may be offline or may fail to process the lock file and not informing the donor network.
  • giffgaff agents may fail to send the lock file to the MVNE. The file may be corrupted. The MVNE may fail to receive or process the file due to human oversight or system failure.
  • The donor network may fail to release its keep numbers at all. It may release only some, or release the wrong keep numbers (e.g. repeat the previous days). It may release them after 3.00pm, or it may even disconnect the number rather than releasing it making it unavailable for porting. The donor network may fail to send the file of released numbers to the MVNE.
  • The file may be corrupted. The MVNE may fail to receive or process the file due to human oversight or system failure.
  • When the MVNE process the files any of the provisioning aspects (network connectivity, billing etc.) may fail if there is a technical fault in the various systems within the network architecture that the MVNE is linking to; or a fault in the interfaces that manage the data going back and forth between these systems.
  • This file may not be sent; could get corrupted, or may not be picked up.
  • There may be technical faults in the back end systems that support and host the giffgaff website that prevents the site from being correctly updated.

Here is a quick video that will guide you through all the steps.


Ask our community

Don't be shy. Ask one of our lovely members for help.
Our community won't let you down.

Ask a question