To change IT or phone providers safely, confirm ownership, document access and records, agree the migration plan, test calling and recovery, and keep a rollback option before switching off the old service.
Most businesses do not leave a technology provider because of one dramatic failure. They leave because response times drifted, nobody could explain the invoice, or the person who knew their setup left two years ago.
Then they stall — because switching feels riskier than staying. That instinct is not wrong. A badly run transition can cost far more than another year of mediocre service. But the risk sits in specific, identifiable places, and each one can be dealt with before anything is switched off.
Find out what you actually own
Before you talk to anyone new, establish what is yours. This is the single most useful thing you can do, and it is uncomfortably common to discover the answer is “less than we assumed”.
Work through:
- Domain names. Who is the registrant — your business, or your provider? Who controls the DNS? This is the one that causes the most damage when it goes wrong, because email and website both depend on it.
- Microsoft 365 or Google Workspace tenancy. Is it your tenancy with your provider holding admin rights, or their tenancy with you as a guest? These are very different situations to unwind.
- Phone numbers. Numbers are generally portable, but portability depends on the current carrier and the number type. Confirm it before you plan a cutover date, not after.
- Licences and subscriptions. Bought in your name, or resold through the provider? Resold licences usually need reissuing rather than transferring.
- Backups. Where do they physically live, how far back do they go, and can you get them out in a usable format?
- Hardware. Owned, leased or provided? Firewalls and switches are sometimes the provider’s, and leave when they do.
You are not being adversarial by asking. Any reasonable provider expects these questions, and the answers determine everything that follows.
Get the documentation before the relationship cools
The most valuable thing a departing provider holds is knowledge, and it is the thing least likely to be handed over once notice has been given.
Ask for the network layout, firewall rules, VLANs and static addressing, the server and application inventory, the backup schedule and retention, admin account list, licence records, and any third-party contacts — the ISP, the line-of-business software vendor, the alarm monitoring company.
Ask while things are still cordial. Put the request in writing, and give a date.
If the answer is that none of it is written down, you have learned something important about the last few years, and your new provider needs to know they are starting with discovery rather than a handover.
Sequence it so you always have a way back
A safe transition runs in stages, and no stage removes the old path until the new one is proven.
- Discovery — document the environment as it actually is, not as the diagram says
- Access — new provider gets their own admin credentials, existing access stays untouched for now
- Risk review — identify what genuinely cannot go down, and when the quiet windows are
- Migration plan — written, with an order of operations and a rollback for each step
- Test — prove the new path works before anything is decommissioned
- Cutover — with someone available who knows both the old and new setup
- Decommission — only after a settling period, never on cutover day
The temptation is to compress this. Resist it for anything that touches email, phones or anything customer-facing.
Where transitions actually go wrong
A few specifics, because they recur.
Email. Cutover during business hours, or without a tested mail flow, and you lose messages you will never know about. Migrations should run with both paths live and mail delivering to the new destination before the old one stops.
Phones. Number porting has lead times set by the losing carrier, not by whoever is doing the work. Book the port, then plan the cutover around the confirmed date — not the other way round.
Multi-factor authentication. If MFA is registered to a departing staff member’s phone, or to the provider’s own account, you can lock yourself out of your own tenancy at exactly the wrong moment. Audit who holds the recovery methods before you change anything.
Certificates and renewals. Domain, SSL and licence renewals sitting on the old provider’s card will fail silently, usually a month or two after everyone has moved on.
The last 10%. The scanner that emails PDFs. The old accounting machine. The label printer on a static IP nobody documented. These are found during cutover if you are lucky, and afterwards if you are not — which is why the discovery stage is worth doing properly.
What good looks like
You should be able to see, in writing, what will happen and in what order, what the rollback is at each point, who is doing it, and how success is confirmed. You should know which of your services will have a brief interruption, when, and how long.
If a prospective provider cannot give you that before starting, they have not planned the work — and you are the one carrying the risk.
Bestcomm’s transition approach covers discovery, access and asset documentation, risk review, migration planning, testing and user support before the current service is changed. If you are weighing up a move, call +61 3 8080 8914 and we can talk through what your specific environment would involve.
This article is general guidance. The right approach for your business depends on your current environment, obligations and risk. Scope and inclusions are confirmed during discovery. Call +61 3 8080 8914 to talk it through.