The Email, and What Is Not in It
Migration notices are usually accurate. The problem is not deception; it is scope. The email describes the change from the provider's side, and almost everything that matters to you is a consequence of that change rather than part of it.
"Your plan and pricing are unchanged" is a true statement about your plan and pricing. It is not a statement about your recordings, your integrations, your after-hours routing or your renewal date.
Why a truthful email can still cost you money
Here is the practice manager's email, decoded. Everything in the left column was in the notice. Everything in the right column was true and not mentioned, because it was not the subject.
| What the email said | What it also meant |
|---|---|
| "Transitioning to a new platform" | Call recordings would not be imported. Four years of them, with retention obligations attached. |
| "All your features are supported" | True at a category level. The specific after-hours on-call rotation, built up over years, had to be rebuilt from memory by someone who had not built it. |
| "Your numbers move with you" | They would move to the new platform. Whether they could later move away depended on a registration nobody had checked, and two were registered to a company deregistered in 2021. |
| "Plan and pricing unchanged" | Until the term ended, which was eleven weeks away, with a thirty-six-month auto-renewal nobody had diarised. |
| "No action required" | Accurate: nothing was required for the migration to proceed. Several things were required for it to proceed well. |
Which of the Four Is It?
Read the notice again with this question in mind. It is usually answerable from the wording alone.
Acquisition
Language about a new owner, a group, a family of brands, or a company joining another. Your service, platform and network are unchanged today. Low technical risk now, commercial risk later.
Platform migration
Language about a new platform, an upgraded system, a transition, a new app or portal, or a scheduled cutover date. This is the one with real operational risk.
Product retirement
Language about a product being closed to new customers, no longer sold, no longer supported, or an end-of-service date. There is a deadline and it does not move for you.
Commercial change
Language about licensing, tiers, support levels, terms or price. Nothing is being installed or moved. Read the numbers, not the technology.
The combination is normal
An acquisition notice today is frequently a migration notice in twelve to twenty-four months, because running two voice platforms costs roughly twice as much as running one and produces no extra revenue — so platform consolidation is usually part of why the deal made commercial sense in the first place. An acquisition email is best read as advance warning. The preparation that is easy in a quiet quarter is genuinely difficult when compressed into a six-week cutover window.
If It Is an Acquisition
Broadly: little happens now, and the useful work is administrative.
| Usually survives | Usually changes within months |
|---|---|
| Your contract, its term and its pricing — supply agreements normally carry assignment provisions and the acquirer steps into the seller's position. | Support: a different queue, different people, different hours, a different escalation path. |
| Your numbers, if the rights of use were properly recorded in your name. | Your account manager, frequently immediately. An unowned account gets a default renewal offer rather than a negotiated one. |
| Regulatory protections and complaint escalation, which attach to the carriage service provider and follow the service. | The roadmap. Somebody now has two platforms and a financial reason to run one. |
| Whatever service levels are actually written in the agreement — which, for many small-business services, is nothing. | Price, at renewal. This is where consolidation reaches most customers. |
Two things to do. Get the new escalation path in writing and test it once with a low-stakes ticket, so you are not learning it during an outage. And ask the roadmap question plainly: is the platform I am on strategic, and if a migration is planned, when and to what? A straight answer is useful. An evasive one is more useful.
If It Is a Platform Migration
This is where the money and the disruption are. Six checks, and each one is a specific question rather than a general assurance.
- Itemise feature parity yourself. "Everything is supported" is a category-level statement. Write your own list — queues, hunt groups, after-hours rules, on-call rotations, call recording, voicemail-to-email, paging, hot-desking, presence, wallboards, reporting — and get each one confirmed individually, in writing.
- Ask about recordings and call history explicitly. Recordings frequently do not migrate; history usually does not. If you have retention obligations, this is compliance rather than convenience.
- Check your handsets against a supported model list. Some do not carry across, and some need reprovisioning that resets local settings. Use your actual inventory, not a general answer.
- Confirm each number arrives and presents correctly outbound. Migrations are a common cause of calls suddenly presenting the wrong caller ID, which then fails silently to some networks — see why answer rates collapse after a change.
- Verify emergency service addresses after cutover. Per site, per number. Address records do not always carry cleanly, and this is the check with the worst consequences if skipped.
- Re-test your outage diversion path. Your rules for what happens when the internet drops are configuration, and configuration is what migrations lose. Test it deliberately rather than assuming.
The sequencing rule
Export before the cutover, not after. Once a legacy platform is decommissioned, "can you retrieve that for us" has no good answer, and nobody is being difficult — the system is gone. An afternoon of exporting is the cheapest insurance available in a migration you did not choose.
If It Is a Product Retirement
Easiest to plan for, most expensive to ignore. Retirements run in three published stages.
| Stage | What it means for you |
|---|---|
| Closed to new customers | Nothing changes yet. But a product closed to new customers has a finite life whatever the current messaging says, so note it and plan on that basis. |
| Stop-sell | No new services and often no changes to existing ones. This is where it starts to hurt operationally: not being able to add a line or open a site is a business constraint, not a technical detail. The replacement decision should already be underway. |
| End of service | It stops. Be off it well before, with numbers ported and tested, rather than in the final weeks alongside everyone else who waited. |
The pattern repeats identically every time, and the ISDN wind-down is the cleanest example: ceased sale in June 2018, disconnections from September 2019, fully decommissioned by 31 May 2022. Businesses that moved early moved on their own budget cycle. Businesses that waited moved at whatever price and lead time were left. One caution: retirement dates are frequently reported from industry sources rather than one consolidated release, so confirm against your own account notices and not against an article — including this one.
If It Is Just Commercial
No installation, no cutover, no risk to your calls. What changes is arithmetic, and the correct response is to redo it.
| Check | Why |
|---|---|
| What exactly moved — price, licensing model, included features, support tier, or the definition of a user? | A licensing change that reclassifies what counts as a user can raise a bill substantially with no headline price rise at all. |
| Whether anything you rely on moved into a higher tier. | The common shape of these changes. Features you already use become part of a tier you are not on. |
| When it applies — immediately, at renewal, or at a stated date. | Determines whether you have a decision now or a diary entry. |
| What the market looks like at the new number. | A price that was competitive may not be. One comparison quote tells you, and you do not have to act on it. |
The Two-Week Response
Worth running whichever of the four you received. Most of it is one afternoon.
- Day 1 — identify the event. From the notice itself, not from news coverage. The four require different work.
- Day 1 — find the actual contract. Term end date, notice period, whether it auto-renews and for how long, and whether there is a change-of-control clause. Auto-renewal after a provider change is the single most common way businesses become locked to a platform they never chose.
- Day 2 — send the number question. Written confirmation that rights of use are registered in your business name, and that the numbers will be ported out on written request. Two sentences; minutes to answer.
- Day 3 — export. Call recordings within your retention requirement, call history, contact directories. Store them somewhere that is not the platform.
- Day 4 — write two pages. Which numbers terminate where, hours and holidays, queues and overflow, greetings and who recorded them, after-hours and on-call paths, and every integration by name.
- Week 2 — test support. Raise one low-stakes ticket through the new path and see what actually happens.
- Week 2 — ask the roadmap question. In writing, plainly.
- Week 2 — diarise renewal minus ninety days, with a named person against it.
The value of this list is that it is useful anyway
Numbers registered in your own name, an export of your recordings, and two pages describing your routing are worth having whether or not anything is changing. That is what makes this cheap: you are not doing migration work, you are doing overdue housekeeping that happens to make a migration survivable.
The One Thing to Do Today
If you read no further: confirm who holds the rights of use over your phone numbers.
Australian numbers are administered under a national framework in which providers hold rights of use over ranges and allocate numbers from them. Whoever is recorded as the holder decides the number's fate. It is entirely possible — common, in fact — for a business to advertise a number for a decade, pay for it every month, print it on vehicles and windows, and hold no registration over it at all.
Registered to the provider
The number sits in the asset base being transferred. Whether you can take it later depends on the new owner's policy, not on your contract.
Registered to a dead entity
Common after your own restructures. Porting then needs authority from a company that cannot provide it, and untangling that takes months you will not have under a deadline.
Registered to you
Every other decision in this article becomes reversible. This is the whole reason to check.
Send it whether or not anything is changing. The detail is in the 1300 number rental trap, and it applies just as much to an ordinary local number on a van.
Recordings and History: Export Before, Not After
Two different things, both easy to lose, and one of them may be a legal obligation rather than a preference.
| What it is | Why it matters at a migration | |
|---|---|---|
| Recordings | The audio itself. | Frequently not imported to a new platform. If you operate in health, aged care, disability services, finance or any sector with retention expectations, those expectations attach to your business, not to the platform holding the files. |
| Call history | Who called whom, when, for how long, and what happened. | Almost never migrates, and it is what an accountant, a lawyer, an insurer or a complaint response actually asks for. Also your only baseline for judging whether the new platform performs as well as the old one. |
Ask two questions in writing: what is exportable, in what format, and by when. Then do the export while the answer is still yes. Sector-specific retention notes are in the NDIS record-keeping piece and the clinic privacy piece, and both generalise.
Your Dial Plan Is a Business Process
It does not feel like an asset, which is why it goes missing. But the rules about which number rings where, what happens at 5:31pm, who covers the on-call phone over Easter, what happens after three rings and when a queue rolls to a mobile are your operating procedure for the phone. They were built up over years by several people, most of whom have probably left, and they exist in exactly one place: inside the platform being replaced.
| Write down | Because at rebuild time |
|---|---|
| Every number, and where it terminates. | This is the part people think they remember and do not. |
| Opening hours, holidays, and what happens outside them. | Holiday behaviour is discovered on the first public holiday after cutover, which is a bad time to discover it. |
| Queues, their order, their timeouts and their overflow. | Timeouts are the detail that makes a queue feel right or wrong, and nobody remembers whether it was twenty seconds or forty-five. |
| After-hours and on-call rotations. | The most bespoke thing in most systems, and the thing most likely to have been set up by someone who has left. |
| Greetings, and who recorded them. | Re-recording is easy. Finding the person whose voice customers recognise is not. |
| Every integration by name. | "CRM integration" is not a specification. The name of the CRM and the version is. |
Two pages. It converts a rebuild from a discovery exercise into a configuration task, and it is the document you will be glad of at the least convenient moment.
Where This Usually Actually Costs You
Not at the migration. At the renewal that follows it, quietly.
| The pattern | The fix |
|---|---|
| The notice said nothing was changing, so the account was not reviewed at all. | Treat the notice as the trigger for a review. Diarise renewal minus ninety days on the day it arrives. |
| Nobody owns the account during the provider's integration, so renewal arrives as a default offer. | Ask for a named account owner. Accounts with no owner get list pricing. |
| Auto-renewal rolls the term before anyone looks at it. | Find the clause and the notice period today, not in month eleven. |
| Market pricing moved and nobody tested it. | Get one comparison quote. Not necessarily to move — to know. A provider who values the account responds to a real alternative. |
Deciding, Rather Than Drifting
Staying is frequently right. Consolidation is not automatically bad for customers: a larger acquirer can bring better-funded support, a more capable platform and investment that a struggling business could not fund. The failure mode is not staying — it is drifting.
| Reasonable to stay when | Worth moving when |
|---|---|
| The new owner is specifically investing in the platform you are on, and will say so. | Your platform is being maintained rather than developed, and nobody will say what happens after this term. |
| Your numbers are registered to you, so the decision stays reversible. | Your numbers are not registered to you and nobody will confirm portability in writing. |
| Support held up, and the escalation path you tested worked. | Support degraded through the integration and has not recovered in two quarters. |
| The migration delivered real parity and your integrations still work. | The migration lost something you depend on with no committed date to restore it. |
| Renewal pricing is competitive when actually tested. | You are facing a second migration inside three years — moving once to somewhere stable is the smaller disruption. |
If you do decide to move, the mechanics are in what actually goes wrong when businesses switch.
What We Put in Writing
Nobody can promise that ownership structures never change, and a provider claiming immunity from a market-wide trend is not being straight with you. What we can do is tell you our position and put the parts that matter in writing.
We are Australian owned and we operate our own network and platform rather than reselling somebody else's, which is the difference between a fault we can investigate and a fault we can only escalate on your behalf. There is one platform, not a legacy one being quietly maintained while something else is developed, so there is no migration sitting in our roadmap waiting for you. Numbers we allocate are registered with rights of use in your name, and we will confirm that in writing along with confirming that we will port them out on written request. Your recordings and call history are exportable and we will tell you the format before you ask. And we will write down your configuration with you at setup, so the two-page document this article recommends exists from day one rather than being reconstructed under pressure.
In short
Read the email to find out which of four events it is: a change of owner, a platform migration, a product retirement, or a commercial change. They arrive in near-identical language and need very different responses, and an acquisition today is often a migration in a year or two. Whichever it is, do five things in a fortnight: read the actual contract for term, notice period, auto-renewal and change of control; get written confirmation that your numbers' rights of use are in your business name; export recordings and call history while the current platform still exists; write two pages describing your routing, hours, queues, on-call paths and integrations by name; and diarise renewal minus ninety days with a named owner. "No action required" is a statement about the migration, not about you.
Related reading: what goes wrong when you switch, a product retirement in practice, a forced migration in practice, whose number it really is, and how to compare the quotes you get next.
Frequently Asked Questions
My provider emailed to say my service is moving to a new platform. Should I be worried?
Not worried, but not passive either, because a platform migration is the one provider change with real operational risk. The email is probably accurate: it describes the change from the provider's side, and almost everything that matters to you is a consequence of the change rather than part of it. Six things are worth checking, each as a specific question rather than a general assurance. Itemise feature parity yourself, because all your features are supported is a category-level statement — write your own list covering queues, hunt groups, after-hours rules, on-call rotations, recording, voicemail-to-email, paging, hot-desking, presence and reporting, and get each confirmed individually in writing. Ask explicitly about call recordings and call history, because recordings frequently do not migrate and history usually does not. Check your actual handset inventory against a supported model list. Confirm each number arrives and presents the correct caller ID outbound, since migrations are a common cause of calls suddenly failing to some networks. Verify emergency service addresses per site and per number after cutover, as address records do not always carry across cleanly. And re-test your outage diversion path, because those rules are configuration and configuration is exactly what migrations lose. Above all, export everything you can before the cutover date rather than after it.
What happens to my contract and pricing if my telco is acquired?
Generally they continue unchanged to the end of the current term, because supply agreements normally carry assignment or novation provisions and the acquirer steps into the seller's position. Regulatory obligations attach to the carriage service provider, so consumer protections and complaint escalation paths follow the service to the new owner as well, and whatever service levels are actually written into your agreement continue to apply — though for many small-business services nothing was ever written, in which case there is nothing to inherit. What changes in practice, usually within months, is the experience around the contract: a different support queue with different people and hours, an account manager who may no longer exist, and a product roadmap now set by an organisation with two platforms and a financial reason to run one. The commercial effect lands at renewal rather than immediately, and that is where consolidation reaches most customers. So three actions follow from an acquisition notice. Read the actual contract, specifically the term end date, notice period, whether it auto-renews and for how long, and whether there is a change-of-control clause that gives you any right. Get the new escalation path in writing and test it once on a low-stakes ticket. And diarise renewal minus ninety days with a named person against it, because an unowned account receives a default offer rather than a negotiated one.
Will I lose my call recordings when my phone platform changes?
Frequently yes, and it is the loss businesses most often discover too late. Recordings and call history are two separate things and both are at risk. Recordings are the audio itself, and they commonly are not imported into a new platform at all. Call history — who called whom, when, for how long and what happened — almost never migrates, and it is what an accountant, a lawyer, an insurer or a complaint response actually asks for, as well as your only baseline for judging whether the new platform performs as well as the old one. If you operate in health, aged care, disability services, finance or any sector with retention expectations, those expectations attach to your business rather than to the platform holding the files, so this is a compliance matter and not a convenience. Ask two questions in writing: what is exportable, in what format, and by when. Then complete the export while the answer is still yes. The critical point is sequencing: once a legacy platform is decommissioned, a request to retrieve something from it has no good answer and nobody is being obstructive — the system is simply gone. An afternoon of exporting before a cutover is the cheapest insurance available in a migration you did not choose, and the export is worth having regardless.
How do I check that my business phone numbers are really mine?
Send two sentences to your provider and get the answers in writing. Ask them to confirm that the rights of use for the numbers on your account are registered in your business name, and to confirm that on written request they will port those numbers to another provider. Both take a provider minutes to answer, and the replies determine whether every other decision you make about your phone service is reversible. The reason this matters is that Australian numbers are administered under a national framework in which providers hold rights of use over ranges and allocate numbers from them to customers, and whoever is recorded as the holder decides the number's fate. It is entirely possible, and quite common, for a business to advertise a number for a decade, pay for it monthly, print it on vehicles and windows and hold no registration over it at all. Two situations cause real damage. If the numbers are registered to the provider, they form part of the asset base in any transaction and your ability to keep them depends on the new owner's policy rather than on your contract. If they are registered to an entity that no longer trades — common after your own restructures — porting requires authority from a company that cannot give it, and untangling that takes months you will not have under a retirement deadline. Send it whether or not anything is currently changing.
What should I write down about my phone system before a migration?
Two pages covering your dial plan, because your dial plan is a business process that happens to live inside a vendor's software and exists in exactly one place: the platform being replaced. Write down every number and where it terminates, which is the part people are confident they remember and generally do not. Write down opening hours, public holidays and what happens outside them, because holiday behaviour is otherwise discovered on the first public holiday after cutover, which is a poor time to discover it. Write down every queue, its order, its timeouts and its overflow rules, since timeouts are the detail that makes a queue feel right or wrong and nobody recalls whether it was twenty seconds or forty-five. Write down after-hours and on-call rotations, which are the most bespoke element in most systems and the most likely to have been configured by somebody who has since left. Write down your greetings and who recorded them, because re-recording is easy but finding the voice customers recognise is not. And write down every integration by name and version, because CRM integration is not a specification while the name of the CRM is. Two pages converts a rebuild from a discovery exercise into a configuration task, and it is worth having even if nothing ever changes.
A product I use is being retired. How long do I have?
Retirements normally run in three published stages, and the discipline is to work backwards from the last one using real lead times rather than optimistic ones. First, closed to new customers: existing services continue and nothing changes for you yet, but a product closed to new customers has a finite life whatever the current messaging says, so plan on that basis. Second, stop-sell: no new services and often no changes to existing ones, which is where it begins to hurt operationally, because being unable to add a line or open a new site is a business constraint rather than a technical detail, and by this point the replacement decision should already be underway. Third, end of service, when the product stops — and you want to be off it comfortably before that date with numbers ported and tested, not in the final weeks alongside everyone else who waited. The dynamics repeat identically every time. The ISDN wind-down is the cleanest example: ceased sale in June 2018, disconnections from September 2019, fully decommissioned by 31 May 2022. Those who moved early moved on their own budget cycle and their own terms; those who waited moved at whatever price and lead time remained. One caution: retirement dates are often reported from industry sources rather than a single consolidated release, so confirm against your own account notices.
Should I switch providers after mine gets acquired, or stay?
Staying is frequently the right answer and the point is to choose it rather than to drift into it, because consolidation is not automatically bad for customers — a larger acquirer can bring better-funded support, a more capable platform, wider coverage and investment a struggling business could not fund. It is reasonable to stay when the new owner is specifically investing in the platform you are on and will say so, when your numbers are registered to you so the decision remains reversible, when support has held up and the escalation path you tested actually worked, when any migration delivered real feature parity and your integrations still function, and when renewal pricing is competitive once genuinely tested against the market. It is worth moving when your platform is being maintained rather than developed and nobody will say what happens after this term, when your numbers are not registered to you and nobody will confirm portability in writing, when support degraded through the integration and has not recovered after two quarters, when a migration lost something you depend on with no committed date to restore it, or when you are facing a second migration within three years — in which case moving once to somewhere stable is the smaller disruption. The two things that make either choice survivable are numbers registered in your own name and a written record of your own configuration.
