How to Change IT Providers Without Losing Access
Switching managed IT providers should not mean losing access to your users, systems, data or support.
In most cases, an outgoing provider will not suddenly disable a client’s entire IT environment. The more common risk is discovering that your business can still use its systems but cannot fully administer, recover or change them.
Employees may still be able to access Microsoft 365, while the only Global Administrator account belongs to the outgoing provider. Your internet may remain online, but nobody internally knows the firewall password. Backups may still be running, but the new provider may not have permission to restore them.
Nothing appears broken until someone needs to make an important change.
That is why switching IT vendors should be treated as a controlled transfer of access and responsibility—not simply an exchange of passwords.
Here is how Australian businesses can change managed IT providers without losing control or disrupting day-to-day operations.
Can you actually lose access when changing IT providers?
Yes, although it is not always a complete lockout.
There are several types of access that need to be protected:
- User access: Employees can continue using email, files and applications.
- Administrative access: Authorised people can change settings, manage users and resolve technical issues.
- Recovery access: The business can regain control if an account, device or authentication method fails.
- Account ownership: The business can prove to Microsoft, a domain registrar, telecommunications provider or software vendor that it owns the service.
A business may have user access without having the other three.
Problems usually arise when administrator accounts, multi-factor authentication, subscriptions or recovery details are controlled by the outgoing provider. Access can also be disrupted when old management tools are removed before replacements are ready.
The transition therefore needs to cover more than passwords.
1. Identify who controls each critical system
Start by listing the systems your business relies on, including:
- Microsoft 365
- Cloud services
- Servers
- Firewalls and network equipment
- Domains and DNS
- Backups
- Security platforms
- Internet and phone services
- Business applications
For each one, identify:
- Who owns the account
- Who pays for it
- Who has administrator access
- Where password resets are sent
- Which phone or device receives MFA prompts
- Who can contact the vendor for support
This often reveals hidden dependencies.
For example, a domain registrar password may reset through Microsoft 365 email, while the Microsoft 365 emergency account depends on a mobile device managed by the outgoing provider.
Everything may work today, but the business could struggle to recover access if one part of that chain fails.
Before the handover, make sure critical recovery methods use business-controlled email addresses, phone numbers and authorised contacts.
2. Create business-controlled emergency accounts
Your organisation should have independent administrative access to its most important platforms.
For Microsoft 365, this usually means creating dedicated emergency administrator accounts that are separate from everyday user accounts. Microsoft recommends maintaining at least two emergency-access accounts and regularly confirming that they still work.
These accounts should not depend on:
- The outgoing provider’s email address
- A technician’s personal mobile phone
- A former employee
- A single executive’s device
- The same sign-in system used by every other administrator
The same principle applies to your domain registrar, DNS provider, backup service, firewall and major business systems.
These accounts should be securely stored and used only when required. Their purpose is not convenience. They provide a way back into the environment if normal administrator access fails.
Microsoft provides further guidance on emergency-access administrator accounts.
3. Test what the access can actually do
A successful login does not prove that the account has the right permissions.
An account may be able to view Microsoft 365 users but not reset MFA. A backup login may show completed jobs but not allow a restore. A firewall account may provide read-only access.
For each critical platform, complete a safe proof-of-control test.
This may include:
- Creating and deleting a temporary test user
- Exporting a firewall configuration
- Downloading an audit log
- Adding and removing a temporary DNS record
- Resetting a test user’s authentication method
- Restoring a test file
- Opening a vendor support request
The objective is to confirm that both the business and incoming provider have the access required to manage the environment—not merely view it.
4. Find accounts that systems depend on
Not every administrator-style account belongs to a person.
Generic accounts such as admin, service or backupadmin may be used by:
- Scheduled tasks
- Backup jobs
- Printers and scanners
- Applications
- Databases
- Monitoring tools
- Website forms
- Cloud integrations
Changing every password on the first day may therefore create an outage.
A password used by an invoice scanner might not cause an obvious problem until the next invoice run. A scheduled payroll process may fail several days after the transition. A website form may stop sending enquiries without anyone noticing immediately.
Before rotating a credential, identify where it is used. Create replacement access, update the affected service, test it and then remove the old account.
Password changes should complete the transfer—not start it.
5. Secure control of domains and DNS
A domain is not only a website address.
It may also control:
- Email delivery
- Microsoft 365 verification
- Remote access
- Cloud applications
- Phone systems
- Security services
- Website forms
- Digital certificates
Confirm who owns the domain registration, who receives renewal notices and who can access the DNS records.
Your transition documentation should include:
- Registrar details
- Account owner
- Recovery contact
- Renewal and billing information
- Nameservers
- DNS provider
- A complete export of DNS records
Avoid relying only on screenshots. A structured DNS export preserves record types, priorities and other technical details more accurately.
Be particularly careful with TXT and CNAME records. They may look unimportant but can validate Microsoft 365, security products, email platforms and other business systems.
6. Replace management tools in the right order
Managed service providers commonly install tools for:
- Remote support
- Monitoring
- Patching
- Endpoint security
- Backup
- Asset management
The outgoing provider will eventually remove its tools, while the incoming provider deploys replacements.
The risk is the gap between those two actions.
A computer can remain usable while becoming temporarily unmonitored, unpatched or invisible to the support team.
The incoming provider should first deploy its tools to a small pilot group and confirm that they are:
- Installed
- Reporting to the correct platform
- Receiving the correct policies
- Generating alerts
- Allowing remote support
Once the replacement tools have been tested, the rollout can continue across users, servers and locations.
Some security products can conflict if they run at the same time, so the sequence should be based on technical compatibility rather than simply choosing one removal date.
7. Confirm backups can be restored
A green backup dashboard does not prove that your data is recoverable after changing providers.
Before cancelling the old service, confirm:
- Who owns the backup subscription
- Where the data is stored
- Whether historical backups will remain available
- Who controls the encryption keys
- Whether the new provider can perform a restore
- What happens when the old backup agent is removed
Complete at least one controlled test restore.
For example, restore a file into a separate folder rather than over the original. For servers or larger systems, an isolated recovery test may be appropriate.
The Australian Cyber Security Centre recommends regularly backing up important data and testing that it can be restored. Its Essential Eight guidance provides further information.
A backup has not been successfully transferred until recovery has been tested.
8. Document the systems nobody remembers
The largest systems are not always the greatest transition risk.
Smaller processes are often overlooked because they run quietly in the background.
Examples include:
- A scanner that emails invoices
- A website enquiry form
- A monthly finance export
- A boardroom system with a fixed IP address
- A phone system using specific DNS records
- A warehouse device connected through an old account
- A remote office using an undocumented VPN
Create a short “do not break” register covering:
- What the system does
- Who depends on it
- Which account, server or integration it uses
- How often it runs
- How it can be tested
- How it can be rolled back
Pay particular attention to processes that run monthly, quarterly or annually. Daily systems expose failures quickly. Infrequent processes can remain broken for weeks.
9. Give users one clear support path
Users should not have to work out which provider is responsible for an issue.
Before the cutover, confirm:
- The final date for contacting the outgoing provider
- The first date for contacting the new provider
- The support phone number, email and portal
- Who owns existing open tickets
- How urgent issues will be escalated
- What happens outside business hours
- Who will communicate the change to staff
Every open ticket should have one owner, one current status and one next action.
A short overlap period can be useful. The incoming provider can begin accepting new requests while the outgoing provider remains available for historical information and handover questions.
Businesses comparing service models can learn more about Affinity MSP’s managed IT services.
10. Remove old access after the new environment is verified
Once the new provider’s tools and access are working, remove the outgoing provider’s permissions methodically.
Review:
- Administrator accounts
- Microsoft delegated access
- Remote support tools
- VPN accounts
- Firewall access
- API keys
- Backup access
- Security portals
- Domain and DNS access
- Vendor contacts
- Password-manager access
Before removing each account, confirm that a tested replacement exists and that no application still depends on it.
After access is revoked, review sign-in logs, check backup jobs, confirm monitoring is active and test the new support channels.
This provides a clear and defensible end to the former provider’s access.
How Affinity MSP handles provider transitions
Affinity MSP treats onboarding as a controlled transfer of responsibility, not simply a software rollout.
Our process focuses on four areas:
Client-owned control
We identify the systems, subscriptions and recovery methods that should remain under the client’s authority.
Tested access
We verify that administrator accounts can perform the actions required to support and recover the environment.
Managed tool replacement
Monitoring, security, backup and remote-support tools are deployed and tested before outgoing tools are removed, where technically possible.
Support continuity
Users receive clear support details, while open tickets, technical escalations and handover questions are assigned to specific owners.
The goal is to maintain access and support throughout the transition while giving the client clearer visibility over its IT environment.
Learn more about Affinity MSP’s broader IT services and cybersecurity services.
Frequently asked questions
Can an outgoing IT provider lock us out?
An outgoing provider may hold powerful administrative access, but reputable providers should support an orderly offboarding process.
The more common problem is discovering that the client does not have its own administrator account or recovery method. Confirm ownership and access before the old provider’s permissions are removed.
Should we change every password immediately?
No. Some passwords may be used by applications, scheduled tasks and devices.
Identify those dependencies first, create replacement access, test it and then disable the old credentials.
Who should own the Microsoft 365 tenant?
The customer organisation should retain ultimate control of its Microsoft 365 tenant. A managed service provider can receive delegated or role-based access without becoming the owner of the tenant.
What happens to our backups when we change providers?
This depends on the backup platform and service agreement. Confirm how long historical backups will remain available, who controls the data and whether the incoming provider can restore it before cancelling the old service.
How long does switching managed IT providers take?
The timeframe depends on the number of users, systems, locations and technical dependencies.
The transition should not be considered complete until administrator access, monitoring, backups, security and support processes have been tested.
Change providers without giving up control
Switching managed IT providers should leave your business with better visibility and stronger control than it had before.
A good transition confirms who owns each system, who can administer it, how access can be recovered and when the outgoing provider’s permissions can be safely removed.
Affinity MSP helps Australian businesses transition their users, systems, infrastructure and IT support services through a structured onboarding process designed to maintain continuity from day one.
