Having first ensured that firewalls, routes and gateway devices are correctly configured, there are two brief steps required to migrate your clients' trunks and both of these steps should be done in the same or similar time frame.  As of June 2015 - to simplify, facilitate and hasten the migration without the need to rely on interacting with the SIP Trunk Plus team - these steps can, and should, now be actioned by resellers.  The steps are detailed below.

Step 1: Via the Client PBX, Change the 'Proxy' / 'Registrar' Setting...

Without changing 'SIP Domain' that you have set on your reseller 'Options' page on the SIP Trunk Plus portal, and similarly without changing the 'Domain' / 'Realm' on the PBX, you will need to change the 'Proxy' / 'Registrar' on your clients' PBX.  Below is an example of changing this setting on a 3CX PBX (for a reseller that has their 'SIP Domain' set to be sip.500.uk.com on the 'Options' page on the SIP Trunk Plus portal).

(a) once logged into the 3CX Management Console go to 'VoIP Providers' and select your SIP Trunk Plus trunk (in the screenshot below, this has been called 'SIPTrunkPlus').

(b) double-click the trunk to view the 'General' tab then modify the 'Outbound proxy hostname or IP' to be sip.sip-trunking-services.com (or alternatively change this setting to a DNS CNAME Record that you have set up on your own domain to point to sip.sip-trunking-services.com, if preferred).  Please do not change the 'SIP server hostname or IP', which should remain as sip.500.uk.com (or should remain as detailed on your 'SIP Domain' setting on the 'Options' page of the SIP Trunk Plus portal):

Ensure the settings are applied/saved.  Outbound calls will now functional as normal via our new architecture and you are ready to complete the migration process for by following Step 2 below, which will then allow inbound numbers to also function successfully.

The above is an example for a 3CX PBX: a similar process will apply for other PBX systems.  Note that in making the above change, your client's PBX will then use sip.sip-trunking-services.com as the proxy to send and retrieve requests, and your client's trunk will register via our new architecture (which accessible via https://sip.sip-trunking-services.com/admin/).  Our new architecture is 'mirrored' with our current architecture (which is accessible via https://sip.500.uk.com/admin/) operating 'master-master' replication so any changes you make on one will be reflected in the other, with the notable exceptions of the portal's 'Registrations' tab which will only show trunks that are registered on the system in question.

Step 2: Via the SIP Trunk Plus Portal, 'Repoint' Your Client's Numbers...

(a) log into the SIP Trunk Plus portal (which is accessible via https://sip.sip-trunking-services.com/admin/, and/or is accessible via any DNS A Record that you have set up on your own domain), click on the client account and go to the 'Migration' tab.  Follow the instructions detailed by first selecting your client's trunk via the 'SIP Account' edit box, then entering the 'SIP point' you wish to point the number associated with that trunk to.  In the example below, all numbers associated with SIP account / trunk 01727515510@sip.500.uk.com will be directed to the new architecture via sip-peering.sip-trunking-services.com (as opposed to the current architecture, via sip-peering.500.uk.com):

(b) once you have selected the trunk and entered sip-peering.sip-trunking-services.com in the 'SIP point' field, click 'Repoint' which will then repoint the numbers associated with the 'SIP account' to inbound route to the new architecture.

You will be able to see the status each number associated with the trunk in a short report that will be produced: numbers that have successfully been reported will show as 'Success'; numbers that have not been successfully repointed will show as 'Failed'.  'Failed' numbers may be spoofed numbers, in which case 'Failed' can be ignored (but in the unlikely event you see 'Failed' for other numbers please contact us via support@500.uk.com detailing the the client, trunk and failed numbers).

This completes the migration process for the trunk.  Repeat for other trunks / clients as required.