Switching IT providers? What a good first 30 days covers

Changing IT providers is mostly about access, documentation and a security baseline. Here is the typical order of work in the first month, what to prepare before day one, and how to tell whether onboarding actually went well.

What is onboarding actually for?

Onboarding is how a new IT provider goes from knowing nothing about your environment to being able to support it, secure it and recover it. Done well, you end up with three things you may never have had before: an accurate record of your IT, admin access that your business controls, and a known security starting point.

Think of "the first 30 days" as a way to describe what a good onboarding covers, not a promised timetable. The order below is a typical sequence. A five-person office with Microsoft 365 and laptops moves faster than a multi-site organisation with on-premises servers, a phone system and a line-of-business app, and the services you choose change the pace too. For our own managed security service, for example, onboarding is as soon as 1 week, and within 4 weeks, depending on the services you choose. Some steps overlap. What matters is that none of them gets skipped.

Stage 1: Discovery and documentation

The provider needs to know what exists before they can secure it. Expect them to document:

• People and accounts: every user, shared mailbox, service account and admin account, and who each belongs to.
• Devices: laptops, desktops, phones and tablets that access company data, servers, network gear (router, firewall, switches, wireless), printers and anything else on the network.
• Software and services: Microsoft 365 or other email, line-of-business apps, accounting software, cloud storage, the website and who hosts it.
• Network: internet connections, firewall rules, remote access, Wi-Fi networks and any segmentation.
• Third parties: software vendors, the phone provider, the website developer, and anyone else with access to your systems.
• Domains: where your domain names are registered, who controls the DNS, and when they renew.

ASD’s guidance on moving to ASD Essentials asks organisations to continuously identify and document infrastructure, operating systems, applications, identities, credentials and data as distinct assets. You don’t need a framework to see why. An unknown laptop or forgotten admin account can’t be patched, monitored or removed.

Check: you receive a written asset and account list, and it matches what you know is out there. If you know of a device or account that isn’t on it, say so.

Stage 2: Access handover, done securely

This is the part most likely to go wrong, and the part that matters most if the relationship with a previous provider ended badly.

Your business should own the keys. The new provider should get named admin accounts of their own, not a shared login. Your organisation should hold ownership of the Microsoft 365 tenant, domain registrations, DNS, firewall and any cloud subscriptions, with your own contact details on them.

Credentials never travel by email or text. Passwords should be shared through a password manager or entered in person, then changed. Any credential that a previous provider knew should be treated as known to someone outside the business and rotated.

The old provider’s access is removed and verified. That means their user accounts, any remote access tools they installed, VPN accounts, firewall admin accounts and saved credentials. In Microsoft 365, partners can hold delegated admin rights. Microsoft’s documentation shows that you can see and remove these on the Partner relationships page of the Microsoft 365 admin centre by selecting the partner and choosing Remove roles. Agree the timing with both providers so there’s no gap in support.

Emergency access is set up properly. Microsoft recommends two or more cloud-only emergency access ("break glass") accounts with the Global Administrator role, not tied to any one person, using phishing-resistant sign-in such as a passkey (FIDO2) security key, stored securely, monitored, and tested at least every 90 days. Microsoft also recommends assigning Global Administrator to fewer than five people.

MFA on admin accounts is tied to the business. If an admin account’s MFA is registered to a former staff member’s personal phone, fix that now.

Check: there’s an access register listing every admin account, who holds it and what it can reach. The previous provider’s accounts are shown as removed, with the date. Your business is listed as the owner of the tenant, domains and subscriptions.

Stage 3: The security baseline

A security-first provider applies a baseline early, because each item on it closes a common way in.

On backups, ASD’s ASD Essentials guidance is specific: regular backups to secure storage protected by "immutable, offline, logically isolated or equivalent controls", repositories isolated from primary systems, and regular testing to show recovery time and recovery point objectives can be met. A backup job that reports "success" is not the same as a restore that worked. Ask for the test.

On MFA, ASD’s guidance has moved to phishing-resistant MFA. Your provider should tell you where you stand now and what moving to phishing-resistant methods would involve, starting with admin accounts.

Check: you’ve seen the evidence column for each row, not just been told it’s done.

Stage 4: Microsoft 365 review

For most organisations, Microsoft 365 is where email, files and identities live, so it gets its own review. A typical review covers:

• Sign-in protection: whether security defaults or Conditional Access policies are in place. Microsoft’s security defaults require MFA registration for all users, require MFA for administrators, block legacy authentication protocols and block device code flow. Organisations with Entra ID P1 or P2 licences usually use Conditional Access instead, for finer control.
• Admin roles: who holds Global Administrator and other privileged roles, and whether admins have separate accounts for admin work.
• Mail flow: forwarding rules that send mail outside the organisation, mailbox delegation, and email authentication records (SPF, DKIM and DMARC) for your domains.
• Sharing: external sharing settings for SharePoint and OneDrive, guest accounts, and links shared with "anyone".
• Licensing: whether licences match the people using them, and whether your licence tier includes security features you’re paying for but not using.
• Logging: whether audit logging is on, so there’s a record to investigate if something goes wrong.

Check: you get a written list of findings ranked by risk, not a general "looks fine".

Stage 5: Quick wins versus planned projects

By this point the provider will have a list of findings. Good onboarding separates them into two groups.

Quick wins are low-cost, low-disruption fixes that reduce risk straight away. Common examples: turning on MFA for the last few accounts, removing a departed staff member’s access, deleting an external forwarding rule, enabling audit logging, or removing local admin rights from staff laptops.

Planned projects need budget, scheduling or a business decision. For example, replacing a server that’s leaving support, moving file shares to the cloud, segmenting the network, or replacing an unsupported line-of-business app. These should come back to you as a short written roadmap with the reason, the risk of waiting and the options, so you can decide.

Check: you have both lists in writing, the quick wins are marked done or scheduled, and every planned project has a decision owner on your side.

Expect a settling-in period after the switch, too. A good provider watches closely once they take over, fixes teething problems and tunes alerts before day-to-day service becomes routine.

What should your business prepare before day one?

Most onboarding delays come from waiting for information only you have. Gather what you can of this list before you start. Gaps are normal, and finding them is part of the provider’s job, but every item you hand over saves time.

Contracts and accounts

• Current IT provider contract, notice period and exit terms
• Microsoft 365 (or other email) subscription details and the billing account
• Domain registrar and DNS host for each domain
• Internet service details for each site
• Software subscriptions and line-of-business app vendors, with support contacts
• Website host and developer contact

People

• A current staff list, including who has left recently
• One person on your side who can approve changes and make decisions
• Contacts for any third party with access to your systems

Systems

• The systems you can’t operate without, in order of importance
• Known problems, recurring issues and anything "we don’t touch because it might break"
• Any documentation the previous provider left, however incomplete
• Any compliance or contract requirements (government supplier conditions, insurance questionnaires, ISO 27001 scope)

Access

• A list of the admin logins you know about (the list, not the passwords)
• Confirmation that the previous provider has been given notice and will cooperate with the handover

How do you judge whether onboarding went well?

At the end of onboarding, you should be able to answer "yes" to each of these, and see the evidence:

1. We have an asset list of devices, accounts, software and services, and it matches reality.
2. We have an access register. Our business owns the tenant, domains and subscriptions. The previous provider’s access is removed.
3. MFA covers every user and admin, with any exceptions documented.
4. A restore has been tested, and we know the date and the result.
5. Every device has endpoint protection and patching, and the counts match the asset list.
6. The Microsoft 365 findings are written down, with quick wins done or scheduled.
7. We have a roadmap of planned projects with reasons and options.
8. Staff know how to get help, and know how the provider will contact them (so they can spot someone impersonating IT).
9. We know what the service agreement covers, including how requests and incidents are handled, as agreed in writing.

Treat each "no" as a gap to raise now. If several are missing, you’re relying on promises rather than evidence, and it’s worth asking for the missing items before the relationship settles into routine.

Where to go next

If you’re weighing up a change, our managed IT page explains how we approach security-first IT management, and the managed IT support page covers the helpdesk, maintenance and regular review side. If Microsoft 365 is your main concern, see our Microsoft 365 services.

Key takeaways

• Onboarding is discovery, access handover, a security baseline and a Microsoft 365 review, in roughly that order. Pace depends on size and what’s found.
• Your business should own every admin account, domain and subscription. The old provider’s access must be removed and the removal checked, including Microsoft 365 partner relationships.
• Ask for evidence: an MFA report, a patch report, a dated restore test and a device count that matches the asset list.
• Sort findings into quick wins and planned projects so you can make decisions with the reasons in front of you.
• Prepare contracts, a staff list, key systems and known admin logins before day one to avoid most delays.

Sources

• Manage emergency access admin accounts, Microsoft Learn
• Microsoft Entra roles guidance, Microsoft Learn
• Security defaults in Microsoft Entra ID, Microsoft Learn
• Customer-led removal of a granular admin relationship, Microsoft Learn
• ASD Essentials transition guide (asset identification, backups, MFA), cyber.gov.au (15 October 2026)
• ASD Essentials for enterprise IT, cyber.gov.au