Changing IT Providers: A Business Handover Checklist

01

Keep The Business In Control While Support Changes Hands

A provider change is not automatically a move to a new email platform, website or domain registrar. Separate the change of support from any proposed technical migration. That makes the scope easier to understand and avoids unnecessary work.

For a Sunshine Coast or Gympie team, the practical question is often: “Who will help us tomorrow, and can they get into the right systems without breaking today's work?” This checklist helps you answer that before the old arrangement ends.

Considering a change? Discuss your Managed IT handover with Ultra IT. Tell us your team size, main systems and intended timing; keep passwords and recovery codes out of the initial enquiry.

02

1. Define What Is Changing Before Giving Notice

Write a short transition brief: why you are changing, the services you want the new provider to manage, the date you are aiming for and who can approve work. Include the business tasks that must keep working, such as receiving enquiries, accessing shared files, booking jobs and processing invoices.

Review your current agreement for notice periods, renewal dates, handover charges and services supplied by other vendors. These details are contract-specific; do not assume changing support cancels software commitments or gives an automatic refund. Seek appropriate advice if there is a contractual dispute.

Ask both providers to identify the handover contact, outstanding work and any dependencies that require a separate project. Put a named owner beside each open question. An unknown backup location or account owner is an item to resolve, not a box to tick as complete.

03

2. Build A Handover Register, Not Just A Password List

Use one register for services, ownership, billing and evidence. Keep the register itself free of passwords; record where approved secure credentials are held instead.

Ask for usable exports or documentation in an agreed format. A screenshot saying everything is healthy does not tell the incoming provider which data is backed up, where alerts go or how to restore it.

04

3. Verify Account Ownership And Authorised Access

Confirm that the business can authorise and recover its important accounts. Identify who controls administrator identities, recovery contacts and multi-factor authentication. Avoid making one provider's personal email address the only route back into a business service.

Give incoming technicians named, attributable access suited to their agreed work. ASD's ACSC guidance for managed providers supports documented boundaries, least-privilege administration, attributable accounts and MFA for remotely accessible management services.

Transfer necessary secrets through an agreed secure channel after the recipients and authority are verified. Do not put a collection of administrator passwords, MFA recovery codes or application keys into an ordinary enquiry form or group email. Do not share a staff member's personal login merely to make the handover faster.

For Microsoft 365, review partner relationships as well as accounts inside the tenant. Microsoft's granular delegated administration model allows explicitly approved, granular and time-bound partner access. The appropriate arrangement depends on the environment; this is not a claim that every provider relationship uses the same model.

05

4. Separate Software Billing From Administrative Access

For each subscription, record the supplier, product, quantity, billing term, renewal date and who will receive the next invoice. Keep a written decision for what stays, transfers or changes later. Avoid ordering replacement subscriptions before checking the existing commitment and required transfer process.

Microsoft distinguishes delegated administrative rights from subscription relationships. Removing a partner's delegated rights need not remove the relationship used for licence renewal. Azure resource roles also need separate review; removing one permission pathway is not proof that all access has ended.

Google Workspace's subscription-transfer guidance describes transfers between Google and resellers, including plan and billing implications. A subscription transfer is distinct from moving mail or files into a new environment. Have the relevant suppliers confirm eligibility, charges, consent and timing before acting; do not promise that prepaid amounts transfer or every change is reversible.

If a tenant or email-platform migration really is needed, scope it separately with dependencies and acceptance tests. Ultra IT can help review Microsoft 365 support and migration requirements without treating every provider change as a rebuild.

06

5. Protect Domains, Email Routing And Backups During The Change

Identify the domain registrar, DNS host, website host and email platform separately. They may be supplied by different businesses. Record the current DNS configuration and who can approve a change; do not change nameservers simply because the support provider is changing.

For .au domains, auDA explains that the domain authorisation code is different from the registrar account login. Recovery information goes to the registered contact, so confirm that contact is current and accessible before any intended registrar transfer. Treat authorisation codes as sensitive information, not general handover notes.

For backups, establish who controls the account, which data is covered and what happens when the outgoing service ends. Agree any permitted export, retention or overlap in writing. Do not cancel the old backup arrangement until the replacement coverage and required historical-data access have been checked.

Choose a proportionate restore test with an authorised technician: for example, recover a non-sensitive test file into a separate location and verify that it opens. Production restoration, encryption-key changes and recovery-policy decisions need a plan appropriate to the actual system. Review business backup and recovery requirements with Ultra IT.

07

6. Set Practical Acceptance Tests For The Incoming Provider

Agree what evidence means the handover is ready. Pick representative staff and workflows rather than accepting a blanket “all systems transferred” statement.

Before the agreed changeover, verify:

Record when each test was performed, who checked it and any limitation. Do not count test enquiries or synthetic transactions as customers. A planned support switch may not require downtime, but any technical changes should have an agreed window, fallback and realistic communication plan—not a zero-disruption guarantee.

• An authorised business contact can access or recover the important service accounts.
• The incoming provider can perform the agreed administration with its own approved access.
• Representative users can send and receive email and open the files they need.
• The website and a controlled, clearly labelled test enquiry follow their expected route.
• Agreed endpoint management, alerts and security responsibilities are visible.
• Backup coverage and the agreed restore test have an identified result and owner.
• Staff know the new support channel and how urgent problems are escalated.
• Open tickets and remaining risks have named owners, rather than disappearing at the changeover.

08

7. Close Out Old Access Without Leaving A Support Gap

After acceptance, review the outgoing provider's complete access footprint with the authorised owner. This may include partner relationships, named accounts, remote-support software, network access, application permissions, API keys, service accounts and alert destinations.

Plan removal or rotation around dependencies. An account or key might power a business integration; changing it without identifying the owner can stop more than the old technician's access. Avoid competing management agents or removing protection before its replacement is active. If there is evidence of compromise, use an authorised incident-response process instead of treating this as routine handover.

Keep a closure record: access reviewed, actions completed, remaining exceptions, outstanding tickets, billing responsibility and the person who signed off. Retain necessary handover evidence securely. Ask how the outgoing provider will handle its retained copies of business data under the relevant agreement; do not assume deletion or a particular retention period.

Once the transition is complete, use our first 30 days Managed IT checklist to agree ongoing priorities. That is the next stage, not a reason to repeat the handover.

09

Ready To Put A Clear Handover Plan In Place?

Ultra IT offers local Sunshine Coast and Gympie IT support with developer-led help for business systems and integrations. We can review the services involved, identify access and ownership questions, and scope the transition around the work your team needs to keep doing.

Managed IT Core starts from $239 per month for up to five eligible devices as a monitoring and maintenance baseline. Support labour, licences, backup, security products, onsite work and transition projects are separately scoped unless the written agreement includes them. A provider handover is not automatically included in that monthly starting price.

For a useful first conversation, send your approximate users/devices, main cloud services, contract or renewal timing and the problem you want the new arrangement to solve. No passwords are needed for that first enquiry.

Plan My IT Provider Handover