How Long Does It Take to Change IT Providers?

Most businesses stay with an IT provider they have outgrown for one reason: switching feels riskier than putting up with the problem for another year. That fear is what keeps a bad arrangement alive, and it is usually built on not knowing what the change actually involves. So here is the plain version. How long it takes, what happens in what order, and what really goes wrong, because once you can see the shape of the work it tends to stop being frightening.

For an Australian business of 30 to 300 users, plan on four to eight weeks from the decision to a clean handover, with the heavy technical work packed into a much shorter stretch inside that window. That range is planning guidance drawn from how these jobs run, not a published benchmark, and your notice period can set the real deadline whatever the technical work says. What moves the number is rarely the difficulty of the systems. It is how much administrative access the outgoing provider holds and will not share, how well the environment is documented, and the notice you are locked into.

Handled properly, most of the change should be invisible to your team. When a transition goes badly it is almost always the same three culprits: access nobody wrote down, a backup nobody ever tested, and a licence or domain registration sitting in the old provider's name instead of yours. Each one is findable before you give notice. That is the whole argument for planning the move rather than reacting to a bad month.

TL;DR: What to remember

• ✅ Four to eight weeks is a realistic window for a 30 to 300 user business, with the intensive technical work compressed into a much shorter stretch inside it.
• ✅ Before you give notice, settle three things: what you own, what you can get into without your provider's help, and whether your backups actually restore.
• ✅ Parallel running is the phase businesses skip and the one that keeps cutover day boring. Skip it and you get the outage you were trying to avoid.
• ✅ The most expensive mistake is giving notice before you have proven you can reach your own systems.

Contents

• Three things to settle before you give notice
• Where the weeks actually go: discovery, parallel running and cutover
• What goes wrong, and how to catch it early
• What to ask a provider before you sign
• A few more things worth knowing before you switch

Three things to settle before you give notice

Do these quietly, in this order, and give yourself about a week. None of them is a hostile act. They are questions a well-run business should be able to answer on any ordinary Tuesday, and asking them early is just good housekeeping. If any of the three draws a defensive reaction, that reaction is information in its own right.

• Work out what you actually own. Your domain name, your Microsoft tenant, your licences, your line-of-business software agreements, your backups. Confirm each is registered to your business and not to your provider. Registrations and cloud tenancies quietly held in a provider's name are a common and awkward discovery mid-transition, and they are far easier to sort out while the relationship is still friendly.
• Get your own way in. You should hold a global administrator account in your own cloud tenant that does not depend on your provider handing you access. If you do not have one, ask for it now, framed as ordinary governance rather than as a warning shot. Any business should be able to get into its own systems without a supplier's cooperation.
• Prove a backup restores. Ask for evidence of a recent restore that someone actually ran and checked, not a backup report that says the job completed. A completed job means a copy exists somewhere; only a tested restore means you could rebuild from it. Mid-switch is a rotten time to discover the gap between those two.

Where the weeks actually go: discovery, parallel running and cutover

A transition splits into three phases, and they do not take equal time or equal effort. Knowing which phase is doing the real work tells you where a provider is either earning the fee or cutting a corner you will pay for later.

Discovery

Discovery is the new provider documenting what genuinely exists: devices, servers, cloud services, applications, integrations, who can reach what, and what is exposed to the internet. Budget one to two weeks. Where the outgoing documentation is good, it runs fast. Where it is thin, the assessment work quietly turns into the discovery work, and the time doubles. That is not the new provider padding the job. It is the cost of the last provider not writing things down.

Parallel running

Parallel running is where the incoming monitoring, patching and security tooling gets deployed alongside what is already in place. This is the phase businesses underestimate and the phase a competent transition spends its time on, because the entire aim is that nothing has to be discovered on cutover day. It is unglamorous and it is the difference between a smooth change and a scramble.

Cutover

Cutover is the actual handover of administrative control and support responsibility. Done properly it is deliberately dull: the helpdesk number changes, the escalation path changes, and the technical control has already moved across in the phase before. Boring is the goal.

One concrete point about the technical end of onboarding, because it is often quoted misleadingly. Once a provider has access to a Microsoft environment, a lot of the hardening work can be automated and run over hours rather than weeks. inSUPPORT's onboarding scripts run over roughly a four-hour window once that access exists. That is one slice of the process, not the whole migration, and any provider quoting hours for an entire switch is describing that slice while letting you assume it covers the rest.

What goes wrong, and how to catch it early

This is the part nobody wants to picture, and it is where the cost lives when a switch goes wrong. The failures are predictable, which is exactly why they are preventable.

• Undocumented access. A system only the outgoing provider could ever get into, found after the relationship has ended. Enumerating every administrative account during discovery, rather than at cutover, is what catches it in time.
• Licences and registrations in the wrong name. Recoverable, sometimes slowly, and much harder to fix once notice has been given and goodwill has drained away.
• Untested backups. The transition is usually when this surfaces, because it is the first time anyone actually tries. Test before you are relying on it.
• Leftover remote access. Agents and remote-support tools belonging to the previous provider, left installed after the handover. Every one is a live path into your environment held by a party with no current relationship to you. Removing them is a specific cutover task, never an assumption.
• Knowledge that lived in one person's head. Unavoidable in part, and shrunk by insisting that documentation is a deliverable of the transition and not a favour.

Add one more that almost nobody plans for: the outgoing provider's private knowledge of your security exceptions. Every environment carries controls that were deliberately relaxed for a reason. A system that could not take multi-factor authentication. An application that needed a privileged account. A firewall rule opened for a project and never closed. If those decisions live only in the old provider's memory, the new provider inherits them as anomalies instead of as decisions, and will either unwind something load-bearing or leave a real gap in place because it looks intentional. Ask for the exception list explicitly, in writing, as part of the handover.

The outcome people fear most, staff losing email or files for days, is almost always the result of a rushed cutover with no parallel running behind it. That is a planning failure, not an inherent risk of switching. It is also the strongest argument for insisting on the parallel phase even when a provider offers to move faster without it.

What to ask a provider before you sign

The Australian Signals Directorate (ASD) publishes guidance on managing your security when engaging a managed service provider, along with a set of questions to put to a provider before you engage them. It is worth reading, partly because it is short and partly because it is aimed at the provider's own practices rather than at what they are trying to sell you. Its themes include whether the provider administers its own systems securely, whether it monitors activity across its systems and services, whether it regularly assesses itself for vulnerabilities, and whether it is genuinely prepared to respond to an incident.

That last one is worth sitting with. A managed service provider holds privileged access to many customer environments at once, which makes the provider itself a target. Asking how they secure their own house is not rude. It is precisely the question ASD tells you to ask.

Alongside the security questions sit the commercial ones that decide how the relationship actually feels: what the monthly fee covers and what gets quoted separately, who pays when an audit finds a problem, and what the support hours really are against your trading hours. inSUPPORT's support pricing includes security remediation in the support fee rather than billing it back as a separate project, with insurance, backup and security-awareness education quoted as separate, named line items. That is one model among several. The point is not that it is the only sensible one. The point is to know which model you are signing before you sign it, the way The 6 Step Cyber Strength System maps the work up front rather than surprising you with it later.

A few more things worth knowing before you switch

Should we tell our current provider we are looking?
That is a commercial judgment, and there is no single right answer. Whichever way you go, do the three preparation steps above first. They are reasonable requests at any time, and they get a lot harder to make once a provider knows the relationship is ending.

What notice period is typical?
Read your agreement rather than assuming, because the notice period and any auto-renewal clause are the two terms that most often catch people out. Check specifically whether notice has to land before a renewal date rather than at any time. Missing that window can cost you a full extra term you never meant to buy.

Can we switch in the middle of a compliance programme?
Yes, and it needs deliberate handling so the evidence trail survives the move. If you are working towards a framework position, the assessment record, exception register and remediation plan should transfer as documents, not as things somebody remembers. It is a good reason to insist those artefacts exist in writing in the first place.

How do we know the transition is actually finished?
Four tests. You hold administrative access to everything you own. Every prior remote-access path has been removed and verified gone. Your backups have been restored from at least once under the new arrangement. And there is documentation you could hand to a third party tomorrow. If you cannot tick all four, the switch is not complete, whoever is now answering the phone.

Citations

• "How to manage your security when engaging a managed service provider", Australian Signals Directorate. Guidance for customers on managing security risk when outsourcing to a provider. cyber.gov.au
• "Questions to ask managed service providers", Australian Signals Directorate. The question set covering secure administration, monitoring, regular vulnerability assessment and incident response preparedness. cyber.gov.au
• "Essential Eight explained", Australian Signals Directorate. The eight mitigation strategies, including restricting administrative privileges and regular backups, both of which are central to a transition. cyber.gov.au

Related Reading

• The Risks of Not Using Managed Services
• What is Cybersecurity
• The 6 Step Cyber Strength System
• What inSUPPORT runs as one operating model

Content reviewed by Probably Genius for accuracy and relevance.

inSUPPORT provides managed IT and cyber security services. It is not an insurer, insurance broker or underwriter and does not hold an Australian Financial Services Licence. Where cyber insurance forms part of a plan, it is arranged through licensed insurance partners and underwritten by the insurer. Cover is subject to the insurer's assessment, the policy terms and the Product Disclosure Statement and Target Market Determination. This article is general information about IT and security practice, not financial product advice, and it does not take account of your objectives, financial situation or needs.