Every IT provider tells you their onboarding is smooth. It's a claim that costs nothing to make and cannot be checked until after you have signed. So I'll tell you what ours consists of, in the order it happens, including the parts that are slow on purpose.
The short version is that we don't touch anything for a while. That surprises people who expect a van full of equipment on day one. The reason is that almost every bad onboarding story I've heard started with someone changing a setting before they understood what depended on it.
First, an assessment that changes nothing
Before any agreement is signed, we run an IT assessment of what you actually have. We record what's running and how old it is, what is licensed and backed up, and what depends on what. We make no changes while we do this, and you do not have to give your current provider notice for it to happen.
I give you that document whether or not you hire us. That's the only honest way to run the step. If the assessment depended on the sale, you would be right to wonder how much of it was written to produce one.
Two things routinely come out of this stage that the business didn't know. The first is something in the environment nobody realized was still running and still costing money. The second is a dependency, one machine or account that a surprising amount of the company quietly relies on. Both are much better to find now than during a handover.
Second, a plain list you can actually read
The assessment becomes a written summary in ordinary language. It covers what's fine, what is near the end of its useful life, what is missing, and what we would deal with first, sorted by what matters to your business.
If the honest answer is that your current arrangement is in decent shape, that's what the document says. I've handed over assessments that concluded exactly that. A business that changes providers for no good reason is a business that will change again in two years.
Third, documentation before credentials
This is the step that separates a calm transition from a bad one, and it is the one most often skipped, because it is invisible to the client.
We write down how your environment works. That covers every system, account, recurring task, renewal date and dependency, plus the reason behind anything unusual. If you are coming from another provider, we build this from what they hand over plus what we find ourselves, because the two are rarely the same picture.
Documentation comes before credentials for a practical reason. Once you hold the keys to a system you did not document, you're one incident away from learning it under pressure. I'd rather learn it on a quiet Tuesday.
Fourth, credentials and the handover
Only now do accounts and access actually move. That includes administrator accounts, domain and DNS control, Microsoft 365 tenancy, backup consoles, firewall and network gear, line-of-business applications, and the vendor relationships behind them.
If you are leaving another provider, we deal with them directly. Refereeing that conversation is not your job, and putting a client in the middle of it is one of the more common unforced errors in this industry. From your side you should see a sequence of scheduled steps.
The other half of this stage is establishing what you own. It's remarkably common for a business to discover at this point that a domain name or a phone number is registered in their provider's name. Finding that out during a planned transition is an administrative task. Finding it out during an argument is something else.
Fifth, the day your staff notice anything
Your people get told how to reach us and what to expect, in one short message. They call the service desk or use the client portal, and someone who has read your documentation picks it up. That's the whole change from their point of view, and it should be the first day they are aware anything happened.
We keep this deliberately small. An onboarding that asks your staff to learn a new process on top of their actual jobs is an onboarding built around the provider's convenience.
Sixth, the unglamorous work starts running
That means patching, monitoring, backup verification, account reviews, and the maintenance that only gets noticed when it has not been happening. None of it is visible, which is exactly why it needs to be reported. You should be able to see what ran and what it found without asking.
Then we start on the list from stage two, in the order you agreed, at the pace you set. Most engagements begin with whatever hurts most, and the rest follows an agreed schedule.
What we don't do in the first month
We do not replace equipment that is working, and we do not rebuild your network to match a template. The temptation to standardize a new client's environment right away is real, and it is usually about the provider's convenience.
Some of what you have will be fine for years, and I have told clients as much. The list tells you what each item actually costs you to leave alone, and then you decide.
Why the onboarding order matters
Assessment, documentation, credentials, then changes. Reverse any two of those and you get the onboarding people are afraid of: a provider making decisions inside a system it has not finished understanding, for a business that has already committed.
Avoiding surprises comes from doing the slow parts first, which is also why a well-run transition is usually boring to live through. If you're weighing a move, I've also written about why businesses leave their IT provider.
If you want to see what the assessment stage produces before you commit to anything, that's how we start a fully managed engagement, and it is also the first step when a business is switching from another provider. Book a call and I'll set it up.