How to cut over to a new phone system and port your numbers

The short answer

A new cloud phone system can be fully configured and still drop the main line. The failure sits between the old provider and the new one: a number that never moved, a greeting that was not rebuilt, a desk phone that never registered, or an emergency address that still names the office you left.

Work in this order. Inventory every number, call path, device, and emergency address, and name an owner for each. Submit the port only after the request matches the current provider's record. Rebuild the call flows and call them yourself before any published number moves. Choose a staged move or a single date from the risk, and write the day-of checks and the way back while it is still quiet. Then watch the first two weeks, which is when people go back to the old app.

If the platform is not chosen yet, start with the practical guide to choosing UCaaS. It inventories the numbers and decides what one system must own. This guide starts after that decision. If that inventory already exists, start from it. Do not open a second list.

Inventory numbers, paths, devices, and emergency addresses

Sit with the person who answers the main line and the person who pays the phone bill. The admin console is not the inventory. The bill, the website, the email signatures, the trucks, and the ads are.

Numbers. List every number the business is known by: the main line, direct numbers, numbers that only forward, fax lines, conference bridges, and toll-free numbers. For each one, write what answers it today, who owns it, and every place it is published. A number on an invoice and nowhere in the phone system is still a number someone will ask about on the day.

Call paths. For each number, write the path: auto attendant, queue, hunt group, a named person, voicemail, or a forward to a mobile. Include after hours, on call, overflow, and what happens when nobody is logged in. Copy the real hours, including the exceptions, not the weekday default a new console suggests. One owner per path. A shared login is not an owner.

Devices. Desk phones, apps, conference phones, and anything on an analog adapter: fax, alarm, elevator phone, door buzzer, postage meter. Mark what must work the day the number moves, and what can wait. A voice call does not prove an adapter works, so plan a separate test for the fax, the alarm, or the door. Try one new desk phone on the real desk at each site before the day. A phone that takes power from the network switch will sit dark if that switch does not provide it.

Emergency addresses. For each site where someone can place a call, write the address the current provider has on file and the address where people actually sit, down to floor and suite when the form has a place for them. A registered address that still names a former office sends help to the wrong door. Confirm the same address in the new system. Ask which devices at that site will send it, and tell the people on site which phone that is. A mobile app is often the wrong device for that call. Rules differ by location. Confirm with the new provider, and with your own counsel, what your sites require. This guide is not that advice. Do not place a test call to emergency services to check. Ask the provider how they want the address verified.

A professional services office, as an example and not a client story, often finds the main number forwarding to one person's mobile, two direct numbers nobody can name, a fax adapter in a closet, and an emergency address for a suite the team left. That list is the project. If you cannot name the owner of the main number, you are not ready to submit a port.

Build the port order so it matches the record

A port moves a telephone number from the provider that has it today to the new one. Until that move completes, leave the old service in place. Disconnecting first is how a number is lost. Ask the current provider to hold other moves, adds, and disconnects on that account while the port is open. A pending change is a frequent reason a request comes back. Keep the old account up until the numbers you moved have been answering correctly for a window you write down.

Ask the current provider for the customer service record, often called a CSR, and set it next to a recent bill. On a typical local-number port, the request has to match that record: the business name as the provider has it, the service address, the account number, and the billing telephone number, the BTN. Use the provider's own form when its labels differ. Compare the form to the record and the bill before you submit. A suffix on one and not the other, a missing suite, or an account number from an old PDF is enough to send the request back.

The letter of authorization, the LOA, is the signed permission to move the numbers. The signer has to be someone the current provider will accept on the account. Ask who that is before the week you planned to submit, and ask whether a port-out PIN is required. The PIN is often absent from the bill. A missing PIN, or a signature the provider does not recognize, is why a request sits.

The firm order commitment, the FOC, is the date the two providers agree the number will move. It is their date, confirmed after the records match, not the date in the project plan. Ask the new provider what planning range they need once the paperwork is clean, and treat the answer as a range. How long a port takes varies with the providers, the type of number, and whether the records matched the first time. A rejected request starts that wait over. Do not tell the company a cutover date until an FOC is in hand, and describe it as a window.

A full port moves every number on the account, and the old account closes when it completes. A partial port moves a list you name and leaves the rest. Ask whether the BTN has to stay, move, or be replaced before a partial port will be accepted. If the main published number is the BTN and other numbers have to stay behind, settle that before you tell the company the main line can move first.

Toll-free numbers are a separate request. In the US and Canada the change is often a transfer of responsible organization, a RespOrg, rather than the same order as a local number. Texting can be separate too: ask whether messages move with the voice port, and what happens to texts already in flight. Until both sides confirm a shared date, do not plan the greeting on the toll-free number, the texts, and the local main line arriving together.

Ask, number by number, which ones can move. Some cannot: a number in another country, a forward you do not own, a virtual number a vendor will not release. Each of those needs a forward or a replacement, and a list of every place it is published, changed before anything is disconnected. Customers should keep dialing the same number. Change the website, the signatures, and the ads only where a number could not move.

Keep the latest bill, the CSR, the signed LOA, the PIN if there is one, and the number list where the person running the day can open them. When a request comes back, that folder is the comparison.

Rebuild the call flows and test them first

Build the new auto attendant, queues, hours, after-hours rule, and voicemail while the published numbers are still on the old system. Use the temporary numbers the new provider gives you. The port is not the test. If the first time you hear the new greeting is on the FOC date, you are testing in front of customers.

Call each path from a phone that is not on the new system. Use an outside mobile. For each path, write what you expected and what you heard.

A useful minimum: the main greeting and every option a caller can press; each queue, including what happens when nobody is logged in; overflow; the after-hours and on-call path; a transfer to a person and a transfer to a queue; an internal call from one person to another; voicemail, and where the notification goes; one desk phone and one app at each site that must work on day one; an outbound call, and the number and name an outside phone displays. A blank or unexpected name is common until the directory listing is updated, and that update is a separate request from the port. Check it. Do not assume the business name travels with the number. If you record calls, confirm the announcement a caller hears is the one you intend. A default in the new console is not your old announcement.

Emergency addresses are part of the same test. For each site, confirm the registered address in the admin console matches the inventory. Ask the provider how they want it verified. Do not dial emergency services as the check.

The people who answer should place these calls, not only the person who built the menus. A path that makes sense in the admin console and not to the person who takes the call is not done.

Then decide which of those calls must leave a record. A new phone system that logs the call only inside the phone app starts a second inbox on day one. Connect your phone system to your CRM is the pass for which paths write a record, which fields, and a test on three real calls. Do it on the temporary numbers, before the published numbers move.

Choose a staged move or one date

Choose from the risk on the inventory, not from how a launch should feel.

A staged move ports one site, one team, or one group of numbers, and leaves everyone else on the old system. Use it when the numbers can be separated, and when a smaller move will show you the real problems: a phone that will not register, a queue nobody logs into, a published number you missed. Write what has to be true before the next group moves. Do not schedule the next group on the same day you learn the first one. A pilot that never ends leaves both systems half used.

One date moves the numbers together. It fits when the inventory is short, the people who answer have already called the new flows, the devices for that day are in hand, and an FOC is confirmed. If the paperwork is still open, or the emergency address is still the old suite, the plan is hope. Do not set an FOC for a site whose phones have not arrived.

A forward is a dress rehearsal, not a port. Pointing the old number at the new system for an afternoon tells you whether the new greeting answers. It does not move the number, and it can hide a problem that shows up only when the number itself arrives. If you forward, write the time you will point it back, and have someone outside the project call in.

When the platform you selected is RingCentral^®, the work around the product is this same sequence: the inventory, the port, the call flows, and the first weeks of use. The checks do not change with the logo on the admin console. Judge the cutover by the calls you place.

Write the day-of runbook

One page, written before the FOC, with the names of the people who will be available. Include the provider contacts and the account numbers. The person who signed the LOA should be reachable. A port that stalls on a signature you cannot get is a stalled main line. Name one admin who can change a greeting that morning without opening a ticket to the old vendor.

The FOC is a window the providers gave you. Put the checks inside that window. Do not tell the office the phones will flip at a particular minute.

The moment a moved number answers on the new system, call it from an outside mobile and walk the same list you already tested on the temporary numbers. Someone has to be logged into the queue. Write pass or fail as you go, including the emergency address still showing the right place. If the window is during business hours, test the after-hours path by the rule you configured, not by waiting until evening to find it.

One person watches for numbers that did not arrive, with the order in front of them, and calls the new provider. That person does not also answer the main line.

Tell the company in one place what moved and what did not. A thread of guesses is how someone sends a customer to a number that is in the middle of moving.

Leave the old account up. Closing it the same day removes the place a number can still land if the port is only partly done.

Decide the way back before the date

A completed port is slower to undo than a setting. Write the way back in two parts, before the date, and ask the providers what each part actually takes. Do not discover the timing on the day. Treat whatever window they describe as a range, not a promise.

Before the FOC, the way back is to hold or reschedule. Name the one person who may tell the provider to stop, and the condition: a failed test on a path customers will hit, a device that is not in hand, an emergency address that is still wrong. That person should not need a meeting to say it.

After numbers have moved, ask the new provider what a reversal involves. The fast path, when you still have it, is the old system still in service, and a forward or a port back to a number you control. If the old account is already closed, you do not have that path. This is why it stays up. A port back is a new request. It is not a button that returns the morning to the way it was.

Three lines are enough. The trigger: what you will see that means stop. The owner: one person who can call it. The way back: where the next customer call lands, and what you tell the people answering. If you cannot describe that landing, you do not have a rollback.

If you do go back, fix the cause before you name another date. A second FOC on the same broken greeting is the same outage with more notice.

Watch the first two weeks

The cutover is finished when the people who answer are answering on the new system, including the calls that used to land on a mobile or in the old app.

Train those people before you train everyone else on chat and meetings. The first lesson is the path customers hit: how to answer, transfer, and send a call to voicemail, and who to tell when a phone will not register. A one-page card at the desks that went live is more useful that week than a long deck.

For two weeks, the owner of the main line looks at a short list. Missed calls, and whether someone called back. Numbers that still ring an old device. Apps that never signed in. A queue with nobody logged in. Voicemail nobody opens. A device that fails gets a name the same day, not a note that waits for the next project meeting.

Review at the end of the first week and again at the end of the second, with the people who answer. If they are still opening the old app to take the call, the new system is not the phone yet. The next piece of work is that path.

Then remove the old app from the phones that have moved, on a date you wrote down. Leaving it installed, just in case, is how the backup becomes the system.

That stretch, from the inventory through the first two weeks, is the work of communications and workflow optimization: one path for the call, written down, connected to a record, and carried through to the people who answer.

A short cutover checklist

Use this as the cutover and porting checklist. A line is done, or it is not.

Every published number is listed, with what answers it, who owns it, and where it is published.

Every call path has one named owner, including after hours and the case where nobody is logged in.

Devices that must work on the day are listed, including analog adapters, and the rest are explicitly later. One new phone has been tried on the real desk at each site.

Each site's emergency address on the new system matches where people sit, and the provider has said how they want it verified.

The customer service record, the bill, and the port form match. The letter of authorization is signed by someone the current provider will accept, and any port-out PIN is in the folder.

Toll-free and texting are on their own requests, and no one is treating them as the same moment as the local port until both sides have confirmed a date.

Call flows have been called from an outside phone, by the people who answer, on temporary numbers, before any published number moves.

The calls that must write a CRM record have been tested on those same numbers.

Staged or one date is chosen, the devices for that day are in hand, and an FOC window is confirmed before the company is told a date.

The day-of page names who checks, who calls the provider, and who tells the company what moved.

The way back is written for before the FOC and for after, and the old account stays up until the moved numbers have been answering correctly.

The people who answer have a one-page card, and a named owner reviews missed calls and old-app use at the end of week one and week two.

Bring the inventory and the port folder to a working session. Book a strategy assessment and we will use them as the agenda: which numbers move, which stay, and what would make you turn back.