Optional analytics. Your choice.

With your permission, Microsoft Clarity helps us understand visits, interactions and whether enquiries or bookings complete. Declining keeps optional analytics off. You can change your choice in Cookie settings. Privacy policy.

Home/Field notes/What to prepare before changing IT providers

What to prepare before changing IT providers

A practical handover checklist for smaller businesses: account ownership, access, subscriptions, support responsibilities and the checks to agree before switching IT provider.

30 October 2026·5 min read·managed-itBy Lee Eccleston

Before changing IT providers, get four things clear: which systems your business owns, who controls access, what is being handed over and when the new provider takes responsibility. A short written plan makes it easier to keep everyday work moving while the support arrangement changes.

This checklist is a starting point for a smaller business planning a handover. The detail depends on your systems, contracts and the work you are asking the new provider to cover.

Start with a short inventory

List the services the business relies on. A useful first pass includes:

  • Your domain registration, DNS and website hosting.
  • Microsoft 365 or Google Workspace, including email and shared files.
  • User accounts, administrator access and device management.
  • Backup services and the information needed to restore important data.
  • Internet connections, business phones and essential applications.
  • Licence subscriptions, renewals and other supplier arrangements.

For each, record a business contact, the current provider, the account owner, renewal date and where the documentation is kept. Record who can arrange access rather than putting passwords or recovery codes in the list. Share credentials through an agreed secure method when the relevant access is authorised.

You do not need perfect documentation before having a first conversation. You do need to identify the gaps so they can become part of the transition plan.

Confirm ownership and access

Check which accounts belong to your company and which belong to the outgoing provider. Agree how the incoming team will obtain the permissions it needs, who approves them and how access will be reviewed afterwards. Keep a business-controlled route to the important services.

For Microsoft 365, include delegated partner access in that review. Microsoft explains how customers can view partner relationships and remove granular delegated admin privileges. Have an appropriately authorised administrator use the current procedure at the agreed point in the handover. Record licence and commercial arrangements separately and confirm their terms with the supplier.

An illustrative example: if the only working administrator account is controlled by the outgoing provider, removing that access before testing a business-controlled account could interrupt the handover. Confirm the replacement access works before making the planned change. This is an example of a dependency to check, not a published client incident.

Make the new support scope explicit

Write down the systems covered, who users contact, how issues escalate and which work needs a separate quote. Confirm operating cover, response arrangements, onboarding work and any ongoing reporting with the new provider.

The NCSC's guide to choosing a managed service provider recommends clear responsibilities and incident-reporting arrangements. Use those questions when comparing the proposed service with what your business needs.

Discuss unresolved incidents and known risks before choosing a transition date. Record which issues need immediate attention, which are included in onboarding and which require a separate project. Agree who will approve that work.

Agree a transition and recovery plan

Use a sequence that the business, outgoing provider and incoming provider can follow:

  1. Agree responsibilities, any relevant notice or renewal dates, and the person who can approve the move.
  2. Transfer the agreed documentation and arrange authorised access.
  3. Check the incoming team's access and the business's own access to important services.
  4. Plan any technical changes, their checks and the recovery route if a change fails.
  5. Confirm when staff start using the new support route and when responsibility transfers.
  6. Review obsolete access at the agreed point and record anything still outstanding.

For important systems, define what a successful check looks like. Signing in to a console, sending an email, accessing a shared file and completing a recovery exercise are different checks. Agree which are relevant and who performs them; do not assume one proves all the others.

Once the transition is complete, review obsolete access and confirm that staff know how to get help. Keep an agreed record of what was transferred and any work still outstanding.

A checklist for the handover meeting

  • The service list has a named business contact and an owner for each outstanding item.
  • The business and incoming provider have tested the access they are expected to use.
  • Subscription, renewal and supplier dependencies are recorded.
  • Backup/recovery responsibilities and available evidence are understood.
  • Staff know the new support route and when to use it.
  • Any technical changes have an approver and agreed validation/recovery steps.
  • The outgoing provider's access review has an owner and an agreed time.
  • Remaining issues have named owners and next actions.

Questions for the first call

  • Which systems and contracts do we need to review before you take over?
  • What is included in onboarding, and what would be a separate project?
  • How will existing provider access be removed safely?
  • What will our staff do differently on the first day?
  • What evidence will show the handover is complete?

If you are planning a change, discuss managed IT support. For a focused review of the current tenant, explore a Microsoft 365 health check. If licence changes are part of the move, read our Microsoft 365 licensing checks before agreeing the next step.