What Actually Happened
Optus Loop has been Optus's cloud phone service for small and medium business for years. Thousands of Australian businesses run their main number, their reception flow and their desk handsets on it.
In March 2024, Optus announced it had selected RingCentral to power cloud communications for Australian businesses — described at the time as RingCentral's first global service provider partnership in the Australian market. The result is a co-branded product: Optus Loop with RingCentral. Optus now publishes a separate support hub for it, alongside a notice headed Optus Loop System Upgrade and a page headed Updated Loop migration information — what you need to know, plus a set of how-to articles covering signing in, the RingCentral app, call forwarding and work schedules.
Read the shape of that documentation, not the wording
A genuine upgrade does not require a new support hub, a new sign-in article and a migration information page. Those artefacts only exist when the underlying platform has been swapped and customers have to be taught the new one. The word “upgrade” describes the intent; the documentation describes the reality.
One thing we will not do on this page is invent a date. At the time of writing, we could not verify a single published switch-off date for the legacy Loop platform that applies to every customer. Migrations of this kind are almost always run in waves, with each customer given their own window. Your date is the one in your migration notice, and that notice is the document that matters — not anything you read on a blog, including this one. If you cannot find it, ring Optus Business and ask for it in writing.
Replacement vs Upgrade: Why the Difference Matters
This distinction is worth being precise about, because it determines how much work lands on you.
| A software upgrade | A platform replacement | |
|---|---|---|
| Your configuration | Carries over | Has to be re-created, or migrated by a tool that may not cover everything |
| Your logins | Unchanged | New, on a new system, often issued in bulk |
| Your app | Same app, new version | Different app from a different vendor — every user re-installs and re-learns |
| Your handsets | Keep working | Need re-provisioning, and some models may not be supported |
| Your integrations | Keep working | Reconnect, re-authorise, re-test |
| Your historical data | Still there | May not come across. Recordings and call history are the usual casualties |
| Risk on the day | Low | Real — this is a cutover, and cutovers can drop calls |
None of that is a criticism of RingCentral, which is a large and capable platform used by serious businesses worldwide. It is simply a description of what moving between platforms involves, and it is the same whether you are moving to RingCentral, to us, or to anyone else. The work is in the move, not the destination.
Which leads to the single most useful sentence on this page, and the reason it is worth reading to the end.
The reason most businesses never change phone system
It is not loyalty and it is rarely price. It is that changing is disruptive, and disruption has a cost that is easy to feel and hard to quantify. That cost is the moat around every incumbent provider in this industry. A forced migration drains the moat. You are paying the disruption cost this quarter no matter what you decide — so the marginal cost of considering an alternative has dropped to roughly zero, and it will go straight back up the day after you cut over.
What Changes for a Loop Customer
The specifics depend on your plan, your handsets and which wave you are in, so treat this as the list of things to ask about rather than a description of your particular migration.
The app your staff use
A different desktop and mobile application, with different menus, a different dialler and different presence behaviour. Every user installs it, signs in with new credentials, and re-learns transfer, hold and voicemail. Budget for a genuine training session, not an email.
Your desk and cordless handsets
Handsets are provisioned to a platform. On a new platform they must be re-provisioned, factory reset in some cases, and occasionally replaced where a model is not supported. Ask for the supported handset list before the cutover, and check every model you own against it.
Call flows, menus and hunt groups
Your auto-attendant, ring groups, after-hours behaviour, holiday handling and voicemail-to-email routing all have to exist on the new platform. Some of it may be migrated automatically; the rest is manual. Anything nobody documented is at risk of quietly not being re-created.
Call recordings and history
The most commonly lost asset in any platform migration. If you have retention obligations — financial services, health, NDIS, complaints handling — get a written answer on what is exported, in what format, and by when. Export it yourself as well.
CRM and app integrations
Screen pops, click-to-dial, call logging into your CRM, and anything wired up through a webhook or API all need reconnecting and re-testing. A connector that exists on both platforms is still a new connector with a new authorisation.
Plan, price and contract
New platform, new plan structure. Ask explicitly whether your per-user price, your call inclusions and your contract end date change, and whether the migration resets your term. That last one is worth asking twice.
Two items deserve their own mention because they are the ones that cause harm rather than annoyance.
| Item | Why it is different from the rest | What to do |
|---|---|---|
| Emergency service address | The address associated with your service is what a Triple Zero operator sees. On a new platform it must be set correctly again, per site, and it is easy to overlook because nothing looks broken when it is wrong | Verify it in the new admin console for every location on day one, and again after any user is added |
| The administrator account | If the admin credentials go to one person's mailbox and that person is on leave at cutover, nobody can fix anything and the queue for support is long | Nominate two administrators before the migration and confirm both are on the account in writing |
For a fuller treatment of what goes wrong during any provider change — not just this one — our guide to changing business phone provider without losing calls covers contract exits, device audits and cutover sequencing in detail.
What Businesses Have Reported
We are going to be careful here, because there is a difference between what a company announces and what customers experience, and also between a documented incident and a review on the internet.
What can be said fairly: during 2026, Australian public review sites have carried accounts from businesses describing a difficult migration experience. The recurring themes in those accounts are consistent enough to be worth planning around.
| Reported theme | What it means for your planning |
|---|---|
| Being locked out of the old system at cutover with new credentials arriving by email, without setup guidance | Do not assume you will have overlapping access. Export everything you need before the date, not on it |
| Calls arriving on some lines but not others after the move | Test every number and every path on the day, including after-hours and the numbers nobody rings often. Have the test script written in advance |
| Long support waits during the migration period | Migration windows are exactly when support queues are longest. Do not schedule your cutover the day before your busiest trading week |
| Limited direct communication ahead of the change | Chase the notice rather than waiting for it. Ask for your wave, your date and your migration contact in writing |
Reviews are a biased sample, and still useful
People rarely post a review to say a migration went fine, so public feedback about any large migration skews negative and it would be unfair to read it as the typical experience. What reviews are genuinely good for is telling you which failure modes exist — and a failure mode that several unrelated businesses describe independently is one worth preparing for, regardless of how common it is.
It is also worth noting the wider commercial context, because it affects the decision you are about to make. Large international UCaaS platforms are commonly reported to move price at renewal, and RingCentral is not exempt from that pattern in industry commentary. Whatever your migration pricing looks like, ask what happens at the first renewal after it, and get the answer as a number rather than an assurance.
Eleven Things to Check Before Your Cutover
This list is deliberately boring. Every item on it is something that has bitten a business during a phone platform change, and every one of them is cheap to check a fortnight early and expensive to discover on the day.
| # | Check | Why |
|---|---|---|
| 1 | A written inventory of every number — main lines, direct dials, 1300/1800, fax, alarm and lift lines | Numbers nobody thinks about are the ones that go missing. The lift line is not a joke; it is a compliance item |
| 2 | Your call flows, drawn — what happens on a call at 9am, at 1pm on a Saturday, and on Christmas Day | If it only exists in the old system's configuration screen, it does not survive the system |
| 3 | Every voicemail greeting and IVR recording, downloaded | Re-recording them is a half-day nobody has budgeted, and the new ones never sound the same |
| 4 | Call recordings exported, with a note of the retention period you are required to keep | The single most commonly lost asset in a migration, and the one most likely to be legally required |
| 5 | Twelve months of call reporting exported | You will want a before-and-after comparison, and history rarely migrates |
| 6 | Every handset model listed and checked against the new supported list | Hardware you cannot use is a cost you did not plan for |
| 7 | Emergency service addresses per site | Safety, and it silently defaults to something wrong more often than anyone admits |
| 8 | Two named administrators | Single-person access is how a two-hour problem becomes a two-day problem |
| 9 | Every integration listed with who set it up | The person who connected your CRM four years ago may not work there any more |
| 10 | Your contract end date and exit terms, in writing | You cannot evaluate any option without knowing what leaving costs |
| 11 | A test script — every number, every path, inbound and outbound, plus a Triple Zero address verification | Testing without a written script means testing the three paths you happened to think of |
11
Pre-cutover checks
2
Administrators, never one
0
Cutovers before a peak week
1
Written test script
Your Three Options, Honestly
There are exactly three, and the honest thing to say is that all three are defensible depending on your circumstances.
Accept the migration
Reasonable when your setup is simple, your contract has real time left with real exit costs, and the new pricing is fair. RingCentral is a serious platform. Do the eleven checks, cut over on a quiet week, and get the renewal price in writing before you sign anything.
Negotiate at the migration point
Reasonable when you would rather stay but the terms have moved. Your leverage is never higher than when you are being asked to absorb a migration. Ask for the migration to be done for you, for the term not to reset, and for a capped renewal. Get all three answered in writing or treat the silence as the answer.
Move to a provider you actually chose
Reasonable when you are doing the work anyway. If you must re-train staff, re-provision handsets and re-build call flows regardless, the incremental cost of doing that onto a platform you selected — rather than one selected for you — is close to nothing.
Put plainly: the disruption is fixed, and only the destination is variable. That is an unusual position to be in and it does not last.
| What you are comparing | Stay and migrate | Move elsewhere |
|---|---|---|
| New app to learn | ✗ Yes | ✗ Yes |
| Handsets re-provisioned | ✗ Yes | ✗ Yes |
| Call flows rebuilt | ✗ Yes | ✗ Yes |
| Integrations reconnected | ✗ Yes | ✗ Yes |
| Numbers ported | ✓ No | ~ Yes, but the process is standardised and your provider runs it |
| You chose the platform | ✗ No | ✓ Yes |
| You chose who answers the phone when it breaks | ✗ No | ✓ Yes |
Five of the seven rows are identical. That is the whole argument, and it is worth sitting with for a minute before the migration date arrives and the choice quietly disappears.
Nine Questions to Put in Writing
Ask these of Optus, of us, and of anyone else you speak to. The answers separate providers far more effectively than a feature comparison does, and the willingness to answer in writing is itself informative.
| Question | What a good answer looks like |
|---|---|
| 1. What is my exact cutover date and window? | A date and a time range, in writing, with a named contact |
| 2. Who rebuilds my call flows — you or me? | A clear owner. “It migrates automatically” needs a follow-up about what does not |
| 3. Which of my handsets are supported? | A model-by-model answer against the list you supplied, not a general statement |
| 4. What happens to my call recordings and history? | Format, method and deadline for export. “They are retained” is not an answer |
| 5. Does my contract term reset? | Yes or no, and the new end date if yes |
| 6. What is my price at the first renewal after migration? | A number or a cap. An assurance that it will be “reviewed” is a price rise with better manners |
| 7. Who answers the phone at 7am when it is broken, and where are they? | A support model you can describe to your staff in one sentence |
| 8. Where is my data stored and processed? | A jurisdiction. This matters for privacy obligations and is a fair question of any provider |
| 9. If I want to leave later, what is the process and what does it cost? | A straight answer. How a provider handles this question tells you how they will behave when you are less useful to them |
Question 6 is the one people skip
Migration pricing is frequently attractive, because a migration is a moment when customers are most likely to leave. The renewal after it is where the economics are recovered. A good migration price with an uncapped renewal is not a good deal — it is the same deal with the bill arriving later.
If You Leave: How Your Numbers Move
The fear that stops most businesses from switching is losing the number on the van, the website and fifteen years of directory listings. That fear is largely misplaced, and it is worth understanding why.
Number portability in Australia runs on an industry framework — the Local Number Portability arrangements set out in the Communications Alliance C540 code, which has governed inter-provider porting since the late 1990s. It defines how providers exchange requests, the standard hours and the activation timeframes. The important consequences for you:
| What people fear | What actually happens |
|---|---|
| “I will lose my number” | The number is yours to port. Your losing provider cannot refuse simply because they would rather keep you |
| “The phones will be dead for days” | A simple port completes in a defined window. The cutover itself is measured in minutes, and it is scheduled — you pick the time |
| “I have to do the paperwork” | Your gaining provider raises and manages the port. You supply an authority and a recent bill |
| “My 1300 number is different” | Inbound numbers port too. They are usually simpler than a range of geographic direct dials, not harder |
| “Complex sites are impossible” | Complex ports — large ranges, multiple carriers, mixed services — take longer and need more care. Impossible is not the word; planned is |
The two things that genuinely delay a port are an account name that does not match the authority exactly, and an incomplete number list. Both are fixed by preparation, which is what item one of the checklist above is for. Our guide to porting a business number to VoIP covers the process end to end.
The Structural Lesson Worth Taking
Set the specifics of this migration aside for a moment and look at the mechanism, because it will happen again — to someone, on some other platform, within a year or two.
When a provider resells someone else's platform, three things follow, and none of them are anyone's fault:
The roadmap is not theirs
Features arrive, change or disappear on a schedule set elsewhere. Your provider can advocate; it cannot decide. This is why a feature request into a reseller so often lands nowhere.
The platform can be swapped
Commercial arrangements between companies change. When they do, customers move — not because their service was failing, but because a contract somewhere upstream was renegotiated. That is precisely what a Loop customer is experiencing.
Support has a seam
When a fault sits between the network layer and the platform layer, it sits between two companies. Every business that has waited while two vendors discuss whose problem it is knows the shape of that conversation.
The alternative is a provider that owns and operates what it sells — its own network and its own platform — so that the roadmap, the fault resolution and the commercial relationship all sit in one place. That is not a marketing point; it is the reason a Loop customer received a migration notice and someone on an owner-operated platform did not. We wrote about the underlying argument in Australian owned network infrastructure versus overseas cloud.
What to do this week, in three lines
One: find your migration notice and your cutover date, in writing. Two: work through the eleven checks — most of them are exports you should have anyway. Three: get one comparison quote while the disruption cost is already sunk, because on the other side of your cutover it will not be. Whatever you decide, decide it deliberately rather than by default.
If you want to see what the comparison looks like against a specific bill and a specific set of call flows, that is a conversation rather than a form, and it takes about twenty minutes. Our 2026 comparison of Australian business phone systems is the neutral starting point, and the alternatives guide covers how the large international platforms stack up locally.