IT provider onboarding checklist planning is the difference between a managed service that pays for itself by month three and one that is still guessing your network layout at Christmas. You signed the contract. The sales engineer who impressed everyone has moved on to the next prospect. Somewhere a service desk is now formally responsible for a business it has never actually seen. What happens over the next thirty days sets the ceiling on everything that follows for the rest of the term.

Most businesses treat a switch to a new managed IT services partner as an event: a cutover date, a handover call, a fresh phone number on the intranet. It is not an event. It is a project with a discovery phase, a documentation phase, a security phase and a review phase — and the client has real work to do in all four. A provider who tells you otherwise is selling a smooth sale rather than a smooth transition.

This guide is a practical IT provider onboarding checklist for UK businesses of roughly ten to three hundred staff, written from the client side. It runs week by week from contract signature to the thirty-day review, covering discovery, credentials, monitoring, patching, backups, security baselines, service levels and the commercial small print that only becomes visible once the relationship is live.

One framing point before the detail. The first thirty days are the only period in which you have genuine leverage and the provider has genuine attention. Requests made now get done. The same requests made in month seven join a queue. Treat this IT provider onboarding checklist as a window that closes, because it does.

Table of contents

Why your IT provider onboarding checklist matters most in month one

it provider onboarding checklist first 30 days b magnifier over blank cubes

Every managed service relationship has a honeymoon period, and it is short. The team assigned to your transition is not usually the team that will answer your tickets in March, which is exactly why the knowledge they gather has to be written down rather than remembered.

The honeymoon problem

New providers arrive motivated. They want a reference, a case study and a renewal, so the first month is when you will get engineering time you will never be offered again. Businesses that spend that month politely waiting to be told what to do burn it. Businesses that arrive with a written IT provider onboarding checklist and a named internal owner convert it into documentation, monitoring coverage and fixed problems that would otherwise sit unresolved for a year.

What a competent MSP does without being asked

A good provider drives the transition. They will propose a kick-off, run automated discovery, deploy monitoring agents, audit backups, review your identity configuration and produce a findings report with a prioritised remediation list. If you are being asked what you would like them to do, you have hired capacity rather than expertise, and your IT provider onboarding checklist has just become the project plan for both parties.

What only you can supply

Discovery tools find devices, not context. Only you can explain which system the finance team cannot lose at month end, which legacy application breaks when it is patched, which director travels constantly and which supplier holds the licence keys. Budget half a day of the right person’s time for this. It is the single highest-value hour on the whole IT provider onboarding checklist.

The cost of a transition nobody managed

An unmanaged transition does not fail loudly. It produces a provider who monitors sixty per cent of your estate, holds partial documentation, has never tested a restore and does not know your Cyber Essentials renewal date. Nothing breaks — until something does, at which point everybody discovers simultaneously that the handover was never finished.

Before day one: what to agree in the IT provider onboarding checklist

it provider onboarding checklist first 30 days c server stack orbiting ring

The work that prevents most transition problems happens between contract signature and the first working day, when both sides still have goodwill and nobody is firefighting.

Named contacts on both sides

Get four names in writing: your day-to-day service delivery contact, the technical lead running the transition, the escalation manager above them, and the account owner who can authorise commercial decisions. Then supply the same from your side. Transitions stall on ambiguity about who may approve what, and a two-line table at the top of your IT provider onboarding checklist removes that entirely.

The kick-off meeting that is not a sales call

Insist the kick-off includes the engineers who will actually do the work, not only the account manager. Agree the discovery method, the timetable, the reporting cadence and what “complete” looks like at day thirty. Anything agreed verbally in this meeting and not written into the transition plan will be remembered differently by both parties within a fortnight.

Credentials and the handover pack

You will need to hand over administrative access to your Microsoft or Google tenant, firewall, switches, wireless controllers, backup platform, line-of-business applications and domain registrar. Do it through a password manager with an audit trail, never by email. Where the outgoing provider holds credentials you have never seen, request them formally and in writing — this is the point at which leaving an IT provider becomes complicated, and it belongs on the IT provider onboarding checklist for the incoming relationship too.

The escalation path, agreed while everyone is calm

Write down what happens when a P1 is not moving: who is called, at what elapsed time, and on which number. Agreeing this during a live outage never works. Agreeing it in week zero costs ten minutes.

Week one: discovery and the IT provider onboarding checklist for access

it provider onboarding checklist first 30 days d twin drums circular arrow

Week one is about the provider learning your estate properly. The measure of success is not how quiet it is; it is how many things they find that you did not know about.

Full estate discovery, not a representative sample

Discovery must cover every site, every server, every endpoint, every network device, every cloud tenant and every SaaS subscription — including the ones a department bought on a card. Ask explicitly for the list of things discovery could not reach, because unreachable devices are where the risk lives. A discovery report with no exceptions section is a discovery report nobody read.

Documenting what nobody ever wrote down

Expect the provider to produce a network diagram, an asset inventory, a list of business-critical applications with their owners, and a description of how your backups and restores actually work. Firms already practising disciplined IT asset management will find this fast. Everyone else discovers that the last diagram was drawn in 2019 by somebody who left. This is the deliverable that makes the rest of the IT provider onboarding checklist possible.

Administrative credentials and privileged access

By the end of week one your provider should hold its own named administrative accounts with multi-factor authentication rather than sharing a generic login, and the old provider’s access should be identified for removal on an agreed date — not before cutover, and definitely not three months after. Shared administrator passwords surviving a transition is the most common finding of any post-incident review.

The first real ticket

Raise something genuine and moderately urgent in week one and watch what happens. You will learn more about response times, communication style and internal escalation from one real ticket than from any service level table. Note the result against your IT provider onboarding checklist; it becomes the baseline you measure the thirty-day review against.

Days 8 to 14: monitoring, patching and backup verification

it provider onboarding checklist first 30 days e shield with central keyhole

The second week is where a transition becomes measurable. Everything in this block produces a number, and numbers are what you review at day thirty.

Agents deployed everywhere, not mostly everywhere

Monitoring and management agents should be on every server and every endpoint, with a reconciliation against the asset register proving it. “Ninety-four per cent deployed” is a perfectly good week-two position and a completely unacceptable day-thirty one. Ask for the exception list by name and make closing it an item on the IT provider onboarding checklist rather than a rolling verbal update.

Patch status is your first honest health check

The initial patch compliance report is the most revealing document of the entire transition, because it describes the estate you actually have rather than the one you believed you had. Expect it to be worse than you hoped. What matters is the remediation plan: what gets patched, in what order, in which maintenance window, and which systems cannot be patched and therefore need compensating controls.

Backup verification beats backup configuration

Do not accept “backups are configured and green”. Ask for a test restore of a real file, a real mailbox and, where practical, a full server, with the elapsed time recorded. A backup nobody has restored is a hypothesis. Verified restores are the single item on this IT provider onboarding checklist most likely to matter to the survival of the business, and week two is the right time to prove them.

Asset register and licence reconciliation

Reconcile discovered devices and users against what you are paying for. Transitions routinely surface Microsoft 365 seats assigned to leavers, duplicate antivirus subscriptions and a server nobody can identify an owner for. The savings frequently fund a meaningful share of the first year, and the exercise pairs naturally with an IT budget planning template for the coming year.

Days 15 to 21: the security items on your IT provider onboarding checklist

it provider onboarding checklist first 30 days f balance scale empty pans

Security is the part of a transition most often deferred and least often revisited. Fix the baseline while the provider still has transition engineers assigned.

Multi-factor authentication and conditional access

Confirm MFA is enforced for every user without exception, that legacy authentication protocols are blocked, and that break-glass administrator accounts exist, are documented and are excluded from conditional access deliberately rather than accidentally. Ask to see the policy list, not a verbal assurance. Every serious IT provider onboarding checklist treats identity as the primary perimeter, because for most businesses it now is.

A cybersecurity baseline you can point at

Agree a named standard rather than an aspiration. For most UK SMEs that means aligning to the five technical controls in the government-backed Cyber Essentials scheme, which covers firewalls, secure configuration, user access control, malware protection and patch management. A provider unwilling to state where you currently sit against a published cybersecurity standard is telling you something useful.

Joiners, movers and leavers

Establish how starter and leaver requests reach the provider, how quickly they are actioned, and what proof you receive that an account was disabled. This is the process that quietly protects you from dormant-account breaches, and it should dovetail with your internal IT onboarding and offboarding checklist rather than duplicating it.

Incident response: who calls whom at two in the morning

Agree the definition of a security incident, the notification route, the out-of-hours contact and the point at which your cyber insurer and, where personal data is involved, the ICO must be told. Twenty minutes now removes the worst hour of a future breach from the argument stage.

Days 22 to 30: proving the IT provider onboarding checklist actually worked

The final week is assessment. You are deciding whether the transition is genuinely complete or merely out of the news.

The thirty-day review meeting

Book it before day one, not during week four. Attendees should include the technical lead, the service delivery contact and your internal owner. The agenda is the IT provider onboarding checklist itself, item by item, marked complete, outstanding with a date, or abandoned with a reason. Vague progress updates are how transitions quietly end at eighty per cent.

Metrics that mean something

Ask for five numbers: tickets raised and closed, average first response, average resolution, patch compliance percentage, and monitoring coverage percentage. One month is too short to judge a trend, but it is exactly right to establish a baseline — and a provider who cannot produce these numbers at day thirty will not produce them at day three hundred either.

The documentation handover test

Apply a simple test. If the engineer who ran your transition were unavailable tomorrow, could a colleague pick up your documentation and support you competently? Ask the provider to demonstrate this rather than assert it. Mature IT service management makes the answer routine; personality-dependent support makes it awkward, and the awkwardness is the finding.

Signing off the transition

Close the project formally, in writing, with any outstanding items carried into a dated remediation plan owned by a named person. An IT provider onboarding checklist that simply fades out leaves every unfinished item permanently ambiguous, and ambiguity always resolves in favour of the party doing the work.

Contract and commercial items your IT provider onboarding checklist must catch

Commercial detail becomes visible only once the service is live. Reading it in month one is cheap; discovering it in month nine is not.

What “unlimited support” actually excludes

Unlimited rarely means unlimited. Common carve-outs include projects, out-of-hours work, third-party liaison, hardware installation, site visits beyond a threshold and anything classed as a change. Ask for examples of work done in the last month that was billed outside the retainer. The answer is far more informative than the contract clause, and the same instinct applies when you compare managed service providers before signing.

Response time is not resolution time

A four-hour response target and a four-hour fix are entirely different promises, and most agreements guarantee only the first. Confirm what is measured, when the clock starts, whether it pauses awaiting your input, and what happens when a target is missed. The formal definitions in a standard service-level agreement are worth reading before you accept the provider’s own wording.

Change control and out-of-scope work

Agree a threshold above which work needs written approval, and who may give it. Without one you get either surprise invoices or stalled work, depending on the provider’s temperament. Neither is acceptable, and both are avoidable with a single line on the IT provider onboarding checklist.

Budget visibility

Ask for a monthly statement covering retainer, project work, licences and hardware. Businesses that cannot see the split cannot forecast, and cannot tell whether the relationship is drifting from managed service into billable rescue work.

Data, credentials and exit rights people forget to ask about

The best moment to agree how a relationship ends is while it is beginning and everyone is being agreeable.

Who owns your tenant

Your Microsoft 365 or Google Workspace tenant, your domain names and your primary administrative accounts must be owned by your company, with the provider holding delegated access. Providers holding tenancy in their own name is common, legal and a serious problem the day you want to leave. Verify ownership in writing during week one.

Who owns the documentation

Establish that network diagrams, asset registers, configuration records and passwords are your property and will be exported in a usable format on request. Some providers hold documentation inside a platform you cannot extract from — a fact that only ever surfaces during an exit, when it is worth precisely as much leverage as they need it to be.

Exit clauses written while everyone is friendly

Confirm notice period, the cost of transition assistance, the format of the data return and the timescale for it. If you have ever run the warning signs of an underperforming IT provider against a previous supplier, you already know these clauses decide how painful the next change is.

Red flags your IT provider onboarding checklist should catch in month one

Transitions fail in recognisable ways, and all of them are visible before day thirty if you are watching for them.

Discovery that never quite finishes

If week three arrives and the asset inventory is still “nearly complete”, the transition has stopped. Discovery is bounded work; open-ended discovery means it has been deprioritised in favour of other clients.

The single point of contact who never answers

One responsive engineer is pleasant and structurally fragile. If everything routes through one person and that person is on leave for a fortnight, you have bought a contractor with a company logo, not a managed service backed by a functioning service desk.

Documentation that is a folder of screenshots

Screenshots in a shared drive are not documentation. Structured, searchable, maintained records are. This is one of the clearest quality signals in the entire IT provider onboarding checklist, and it is visible within about ninety seconds of being shown the system.

Silence on security

A provider who has completed thirty days without once raising a security finding has either inherited a flawless estate or is not looking. Assume the latter and ask directly for the risk register.

Your thirty-day IT provider onboarding checklist at a glance

Use this as the summary view. Each block should be closed before the next begins, and nothing should be marked complete on trust alone.

Week by week

Week zero: contacts named, kick-off held with engineers present, credentials transferred through a password manager, escalation path agreed in writing. Week one: full discovery completed with a documented exception list, network diagram and asset inventory delivered, provider administrative accounts created with MFA, first real ticket raised and reviewed. Week two: agents deployed and reconciled, patch compliance reported with a remediation plan, test restores completed and timed, licences reconciled against actual users.

Week three: MFA enforced universally, legacy authentication blocked, security baseline assessed against a named standard, joiner and leaver process agreed, incident response route documented. Week four: thirty-day review held against this IT provider onboarding checklist, baseline metrics produced, documentation handover test passed, transition signed off with dated remediation items.

What good looks like at day thirty

Monitoring coverage at or near one hundred per cent, a patch remediation plan in progress, at least one verified restore, documentation a second engineer could use, MFA everywhere, a named escalation path you have tested once, and a written list of outstanding items with owners and dates. That is a completed IT provider onboarding checklist.

When to escalate, and when to walk

Escalate at day thirty if discovery is incomplete, no restore has been tested or monitoring coverage is below ninety per cent — and put it in writing to the account owner. Consider your position seriously if the same items are still outstanding at day sixty, because a provider who cannot deliver during the period they are trying hardest is describing their ceiling, not their starting point. An honest IT provider onboarding checklist gives you that answer in weeks instead of years.