Every IT provider tells you their onboarding is smooth. It is one of those claims that costs nothing to make and is impossible to check before you have already signed. So rather than tell you ours is smooth, here is what it consists of, in the order it happens, including the parts that are slow on purpose.
The short version is that we do not touch anything for a while. That surprises people who expect a van full of equipment on day one. The reason is simple: almost every bad onboarding story we have heard started with somebody changing a setting before they understood what depended on it.
First, an assessment that changes nothing
Before any agreement is signed, we look at what you actually have. What is running, what state it is in, how old it is, what is licensed, what is backed up, and what depends on what. We make no changes during this, and you do not have to give your current provider notice for it to happen.
You get that document whether or not you hire us. That is not generosity, it is the only honest way to run the step. If the assessment were contingent 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 did not know. The first is something in the environment that nobody realized was still running, still costing money, or still holding data. The second is a dependency: one machine, one account, or one line item 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. What is fine, what is close to the end of its useful life, what is missing, and what we would deal with first. It is sorted by what genuinely matters to your business rather than by what is easiest for us to sell.
If the honest answer is that your current arrangement is in decent shape, that is what the document says. We have handed over assessments that concluded exactly this, and it is not an act. 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 step most often skipped because it is invisible to the client.
We write down how your environment works. Every system, every account, every recurring task, every renewal date, every dependency, and 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.
The reason this comes before credentials is not procedural neatness. It is that once you hold the keys to a system you did not document, you are one incident away from learning it under pressure. We would rather learn it on a quiet Tuesday.
Fourth, credentials and the handover
Only now do accounts and access actually move. Administrator accounts, domain and DNS control, Microsoft 365 tenancy, backup consoles, firewall and network gear, line of business applications, and the vendor relationships that sit 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. What you should see from your side is a sequence of scheduled steps, not a series of surprises.
The other half of this stage is establishing what you own. It is remarkably common for a business to discover at this point that a domain name, a software license, or a phone number is registered to their provider rather than to them. 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 rather than a training course. They call or email the service desk, and someone who has read your documentation picks it up. That is 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 requires your staff to learn a new process on top of their actual jobs is an onboarding designed around the provider's convenience.
Sixth, the unglamorous work starts running
Patching, monitoring, backup verification, account reviews, and the maintenance that only gets noticed when it has not been happening. None of this 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 a schedule rather than an invoice.
What we do not do in the first month
We do not replace equipment that is working. We do not migrate anything that does not need migrating. We do not rebuild your network to match a template. The temptation to standardize a new client's environment immediately is real, and it is usually about the provider's operational convenience rather than the client's benefit.
Some of what you have will be fine for years. The list tells you what each item actually costs you to leave alone, and then you decide.
Why the order is the whole point
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 they have not finished understanding, on a business that has already committed.
No surprises is not a slogan. It is a consequence of doing the slow parts first, and it is the reason a well-run transition is usually boring to live through. Boring is the goal.
If you want to see what the assessment stage produces before you commit to anything, that is how we start with a fully managed engagement, and it is also the first step when a business is switching from another provider.