SOADSL Migration

Start with an accurate service inventory: a record of which connection belongs to which customer, at which premises and under which supplier reference. Verify contact information and the requested change. A customer name alone is insufficient when the account has several services, and an outdated identifier can prevent the supplier from locating the intended connection.

Check product availability and eligibility at the actual address. The replacement must fit the starting service and supported supplier route. Where relevant, SOGEA provisioning explains that separate single-order product workflow; do not assume it is available or appropriate for every legacy account. Any voice or equipment dependency should have its own agreed handling process.

Establish whether an engineer appointment is appropriate to the chosen route and what access information is needed. Record the requested date and distinguish it from confirmed arrangements. Tell the customer what is changing, what they need to do and how updates will be provided, using information that has actually been confirmed.

Before preparing a batch, test representative records and agree who checks data, submits requests, reviews responses and handles the account transition. The ISP operations guide explains the ownership behind those handovers. Readiness is not just having a customer list; it is knowing that the team can identify and resolve an exception for each service.

Migration order management tracks the request through supplier responses and subsequent progress. Preserve the order and service references so messages can be matched to the right account. Submission, acceptance and completion describe different stages. Staff need to interpret the current response and establish the next action before explaining the position to a customer.

Bulk processing can reduce repeated submission work, but every request still needs valid customer, product and service information. Keep individual outcomes visible. If several orders are progressing and one requires corrected details, the team should be able to follow up that account without losing sight of the others.

For example, one customer may need an appointment while another has an identifier that does not match the supplier record. Those are different investigations with different owners. Record the problem, action and latest communication so a colleague can continue the work. Automation can exchange requests or organise updates; it cannot replace checking the meaning of supplier feedback.

The customer communications guide explains how message content and delivery history support that shared record. When evaluating SOADSL migration tools, ask the supplier to demonstrate a normal request and a mixed-outcome batch, including how outstanding work is found and how a corrected case is progressed.

The customer transition includes the connection, commercial package and relevant charges. Agree who reviews the previous and new service records and what evidence establishes the change. A migration order does not, by itself, answer every question about starting charges, ending charges or adjustments.

Billing software needs the agreed commercial terms and reliable service information. Test how the first bill after migration is checked and how a disputed amount is traced. Requirements for partial periods or final charges should be explicit. The invoicing guide describes the records needed to make a bill understandable and reviewable.

Payment collection continues during the transition. Match received funds to the customer balance, distinguish a failed collection from a disputed charge and preserve previous explanations. If the customer asks why the invoice changed, staff should be able to compare the old and new arrangements rather than relying only on an order date.

Choosing migration software therefore involves more than a successful submission. Evaluate the service inventory, supplier integration, individual and bulk progress, customer updates and financial handover together. A useful demonstration includes an incomplete record, a request needing follow-up and a customer questioning the next invoice. These show whether the process can be operated consistently after the first batch has been sent.

Axiom keeps customer and service information linked with supported migration requests, supplier references, responses and communication history. Through configured broadband integrations, teams can check addresses and returned availability, select the relevant product and prepare the request. Individual and supported bulk workflows retain the details and processing outcome for each order so staff can review exceptions in the affected account.

Engineer booking is optional and available in the migration workflow. The team can arrange an appointment when appropriate for the selected service and supplier process, keeping the relevant customer arrangements with the request. Available migration routes depend on the starting connection, supplier products and configured integration. The workflow does not imply that every legacy service can move to the same destination or that a broadband request resolves separate voice requirements.

For a rejected request, the account and supplier response provide the starting point for checking details and coordinating a customer update.

Linked account, subscription and financial records provide context for reviewing the commercial transition, invoices, payments and balances. Operational Intelligence adds recorded migration events, account notifications and communication history to help prioritise follow-up. Detailed supplier responses and the agreed charging terms remain the basis for the investigation. Bring an existing-service record, the proposed replacement and an individual or bulk scenario to a demo, including the intended billing handover. This makes it possible to evaluate the supported process and identify configuration or partner responsibilities before committing to a programme.