IT Disaster Recovery Services: A Melbourne SME Buyer’s Guide

Melbourne SMEs buying disaster recovery for the first time get stuck between three product categories, unrealistic RTO numbers, and a Microsoft 365 backup conversation nobody told them about. This is the buyer’s guide: what you are choosing between, the realistic 2026 price brackets, and the eight questions to ask any DR vendor before signing.

What this guide is and is not

This is not a planning guide. It is not ‘how to write a business impact analysis.’ It is the conversation you have once you have decided you need to buy something and you are trying to work out what to buy.

Three product categories cover almost every Melbourne SME DR purchase in 2026:

1. DRaaS – replicating production workloads to a cloud target so they can be failed over (Azure Site Recovery is the dominant Australian play, with VMware Cloud Disaster Recovery and Zerto in specialised cases)
2. On-premises BCDR appliances – a local appliance that backs up your servers and can stand them up locally or in the vendor’s cloud (Datto, Axcient, Acronis, Arcserve, Veeam with a hardware partner)
3. SaaS backup – third-party backup for Microsoft 365 and Google Workspace, which the platform vendors do not back up for you (Keepit, Backupify, CloudAlly, Veeam for M365, AvePoint, Dropsuite)

Most SMEs need pieces of all three, in different combinations. A 60-staff professional services firm in Richmond probably needs Azure Site Recovery for the two on-premises servers, a third-party M365 backup, and not much else. A 90-staff manufacturer in Dandenong with a line-of-business ERP, a SQL database, and a need for fast local recovery probably needs a BCDR appliance plus SaaS backup. A 100% cloud-native software company needs SaaS backup plus a workload-specific backup of their cloud database. The product mix follows the workload.

For the planning side of the conversation – the BIA, the RTO and RPO targets, the runbook – see our backup and disaster recovery 2026 guide, which is the companion piece to this one.

Category 1: DRaaS (Disaster Recovery as a Service)

The model is: your production workload runs where it is (on-prem, in Azure, in AWS), and a replication layer copies it continuously to a standby environment in a cloud target. When something fails, you fail over to the standby and run there until you can return to primary.

Azure Site Recovery (ASR)

The default option for Australian SMEs running on Hyper-V or VMware on-prem, or running production workloads in Azure. Replicates VMs to a secondary Azure region (typically Australia East to Australia Southeast, or vice versa). Failover is orchestrated, and you can test failover into an isolated network without disrupting production.

Strengths:

• Native Microsoft, integrates with the rest of the Azure estate
• Australia-sovereign target regions
• Pricing is genuinely SME-friendly: about $25 to $30 per protected instance per month for ASR itself, plus the storage and (during failover) the compute
• Failover testing is non-disruptive and well-supported

Weaknesses:

• RPO is typically 5 to 15 minutes for app-consistent recoveries; not the sub-minute that some marketing claims
• Complex to configure properly; SMEs often deploy it half-configured
• The compute cost during a real failover catches CFOs off guard – if you fail over 12 VMs and run them in DR for two weeks while you rebuild, that is a real Azure bill
• Requires Azure expertise that not every MSP has at the level needed for reliable orchestration

VMware Cloud Disaster Recovery

For SMEs running VMware on-premises with a meaningful estate. Replicates to a VMware Cloud target on AWS or to an alternative pilot-light site. Usually overkill for under-50-VM environments.

Zerto

The premium DRaaS choice. Continuous data protection rather than scheduled replication, RPOs measured in seconds, mature failover orchestration. Priced accordingly. We deploy Zerto for clients who genuinely need sub-minute RPO on critical workloads; it is not the right answer for an average SME.

Category 2: On-premises BCDR appliances

The model is: a physical or virtual appliance lives at your office or data centre, takes regular image-level backups of your servers (and often endpoints), and can either restore locally (fast) or stand the workloads up in the vendor’s cloud (slower, but works if your office is gone).

Datto

The category-defining product. Datto Siris appliances are sold exclusively through MSPs. The local appliance has its own compute, so it can stand up a failed server as a virtual instance on the appliance itself within minutes. Off-site copies replicate to Datto’s cloud (in Australia, hosted in Sydney and Melbourne data centres).

Strengths:

• Fast local recovery; the on-appliance virtualisation actually works
• Cloud failover is real, not theoretical, and Datto runs the orchestration
• Hardware refresh is part of the agreement; the appliance gets replaced on a cycle without a capex spike
• Good for SMEs that want a single thing to point at when the auditor asks ‘show me your DR’

Weaknesses:

• Per-protected-server pricing; can become expensive for environments with many small servers
• Vendor lock-in; getting your backup data out of Datto if you change providers is a project
• Local appliance is a single point of failure for local recovery; needs the off-site copy to be real
• The MSP-only sales channel means you cannot evaluate it without going through a partner

Axcient

Similar concept to Datto, with the local appliance and the cloud failover. Often the right answer for slightly smaller environments where Datto’s pricing is over the budget. The cloud failover capability is solid; the on-appliance virtualisation is functional but slightly less polished.

Veeam with hardware

The build-your-own option. Veeam is the backup software, paired with a Dell PowerEdge or HPE ProLiant or a purpose-built backup appliance (Dell PowerProtect, HPE StoreOnce). More flexible and often cheaper at scale than the all-in-one appliances, but requires the MSP or internal team to design, build, and operate the stack rather than buying it as a service.

This is what we recommend for clients who already have Veeam expertise and who want to avoid the vendor lock-in of the all-in-one appliances. It is what we run in our own environment.

Acronis and Arcserve

Adjacent options in this category, both with valid use cases. Acronis Cyber Protect adds a security overlay (anti-malware, anti-ransomware) on top of the backup product, which appeals to SMEs that want fewer products to manage. Arcserve UDP has a strong reputation for hybrid workloads. Both worth evaluating if Datto and Axcient don’t fit.

Category 3: SaaS backup (the conversation nobody told you about)

The single most common gap we see in Melbourne SME DR posture: Microsoft does not back up your Microsoft 365 data in a way that helps you recover from accidental deletion, ransomware encryption, malicious insider activity, or a SharePoint policy gone wrong. They protect their infrastructure, not your content. This is the Microsoft 365 shared responsibility model, and it is documented in their own service description.

What Microsoft does:

• Geo-redundant storage so a data centre failure does not lose your data
• Retention policies you configure (litigation hold, retention labels)
• Recycle bin and version history for a default period
• Point-in-time recovery for Exchange Online within a window

What Microsoft does not do:

• Full long-term backup of your mailboxes, OneDrive, SharePoint, and Teams content
• Granular recovery to a point earlier than the retention or recycle bin window
• Recovery of an entire tenant if it is wiped by a compromised admin
• Export of mailbox data in a portable, restorable format outside of Microsoft’s tooling

The conversation to have with your IT lead: ‘If a user gets compromised and the attacker deletes the contents of their OneDrive and emails, and we do not notice for 45 days, can we recover the data?’ The honest answer from native Microsoft is usually no – the 30-day default retention window has passed.

Third-party M365 backup tools solve this. Pricing is per-user-per-month, typically $3 to $6 in the Australian market, retention is configurable up to ‘forever,’ and recovery is granular (a single email, a single OneDrive file, a single Teams chat). The leaders:

For every Melbourne SME we manage that uses Microsoft 365 – which is all of them – a third-party M365 backup is part of the baseline stack. We default to Keepit for new deployments because the Australian data residency, retention model, and recovery experience are the best of the options, and the pricing is defensible for SME budgets.

Realistic price brackets for 2026

The number that comes out of a vendor sales call is rarely the number you end up paying once setup, support, replication storage, failover compute, and the inevitable additions are included. Approximate all-in monthly numbers for a 60-user Melbourne SME with 4 production VMs:

Add the implementation cost (typically $4,000 to $15,000 one-off depending on complexity) and the annual failover test (typically half a day of MSP time, billed at the going rate). For most 60 to 100 staff Melbourne SMEs, total DR spend lands between $14,000 and $30,000 per year all-in.

RTO and RPO: what vendors quote versus what they deliver

Vendor marketing materials quote ‘RTO of 5 minutes’ or ‘RPO of seconds.’ These numbers refer to the absolute best-case mechanical capability of the product under controlled conditions on the vendor’s test bench. They are not what you get in a real disaster.

Realistic numbers for the three categories under SME conditions, based on incidents we have run for clients:

The gap between vendor-quoted and realistic is not the vendor lying; it is the difference between the mechanical recovery time and the business-readiness time. When you negotiate, make sure the RTO in the contract is the business-readiness time, not just the time for the system to come up. Otherwise you are signing for a number that does not mean what you think it means.

The eight questions to ask any DR vendor before signing

1. What is your contracted RTO and RPO, and is it measured to system-online or business-ready? If they cannot answer this clearly, walk away.
2. Where is the off-site copy stored, and is the storage in Australia? Sovereign data residency matters for many SMEs, especially those with health, legal or government-adjacent data.
3. What is the additional cost during a real failover (compute, egress, storage)? The DR product price is the steady-state cost; the failover cost can be substantial.
4. How often do you test failover, who tests it, and what is the success rate? Untested DR is a hope, not a plan. Insist on at least an annual test.
5. What does it cost to extract our data if we leave? Vendor lock-in is real. Get the exit number on the contract.
6. What is the support model during an incident – phone, ticket, named engineer? When you are actually failing over, the time to get a human matters more than any other metric.
7. Who else like us are you protecting in Melbourne, and can we speak to them? Reference checks from similar-sized businesses cut through the marketing fast.
8. What is the upgrade and hardware refresh cycle, and who pays? For appliance-based products, this affects the multi-year total cost.

One client of ours – a 40-staff law firm in Kew – went to contract with a national MSP that quoted a 30-minute RTO. The contract small print clarified that 30 minutes was system-online. When we ran their first DR test under our co-managed arrangement, business-ready was 5 hours. We renegotiated the contract on renewal to specify business-ready RTO with measurable check points. Different number, more honest contract.

Sample DR scope checklist (30 to 100 user SME)

The scope of work conversation with a DR vendor is where mistakes get baked in. Use this as a starting checklist:

If a vendor proposal does not cover every row of this table or does not explicitly note items as out of scope with a reason, ask before signing. A DR proposal that omits Microsoft 365 backup is a flag, not because the vendor is dishonest but because the gap will surface during a real incident at the worst possible time.

How TechAssist delivers this

We are vendor-agnostic on DR. Our default stack for a typical Melbourne SME is Azure Site Recovery for IaaS, Keepit for M365 backup, and Veeam for environments that need a richer on-prem appliance story. We also run Datto where it is the right answer and Zerto where the RPO requirement justifies it.

The delivery is what makes the difference. Our 24/7 NOC at Tecoma monitors backup jobs and replication health on every managed client, with sub-15-minute response for P1 events. When a real incident hits, our 13 Australian engineers (no offshore tier-one queue) take the call, and the same-business-day on-site response in Melbourne metro means an engineer can be at your office before lunchtime if hands on the equipment are needed. The per-user fixed monthly pricing model includes the DR management on managed engagements; the DR product cost is a separate, transparent line item passed through at the vendor rate. The two Melbourne offices – Tecoma and 575 Bourke Street CBD – give clients access in both directions of the metro area, with the CBD office useful for CBD-based clients who want a quick face-to-face during planning.

Founded in 2014, our DR practice has now run incidents across professional services, healthcare admin, manufacturing, and not-for-profit clients. The pattern across all of them is the same: the DR posture that works is one that has been tested, documented, owned, and reviewed annually. The product choice matters less than the discipline around it. To talk through your specific environment, our team is reachable through the contact page, or for the broader managed services context the Melbourne managed IT services page covers how DR sits in the overall engagement.

Frequently Asked Questions

Is Microsoft 365 backup really necessary if we have litigation hold?

Litigation hold is a retention control, not a backup. It prevents end users from permanently deleting items, but it does not protect against a compromised admin wiping the tenant, does not give you a portable export, and does not provide point-in-time recovery for arbitrary historical states. For any SME holding meaningful business data in M365 – which is all of them – a third-party backup is a baseline control, not an option.

Can we just rely on the local appliance and skip the cloud failover?

If the disaster is a ransomware attack that encrypts the local appliance, or a fire that takes the office, the local-only configuration is no protection at all. The cloud or off-site copy is what makes the DR posture survive a real disaster. Local appliance plus cloud copy is the minimum; local-only is not DR, it is backup with extra steps.

What is the difference between backup and disaster recovery?

Backup is the data; DR is the ability to operate from that data after a major incident. A nightly backup of your server is backup. The ability to fail that server over to a working environment within a contracted time is DR. Most SMEs need both, in coordinated form, not one or the other.

How often should we test failover?

At least annually for a full test, quarterly for component tests, and continuously for the automated health checks the platform should be running. A DR plan that has not been tested in 18 months is no plan; it is a hope.

Will our cyber insurance cover the cost of a DR failover?

Sometimes yes, sometimes no. Read the policy. Many cyber policies cover business interruption losses but exclude or limit the actual restoration costs. The cleanest approach is to budget for the failover cost as a separate line, and treat any insurance recovery as upside.

Does the same DR product work for our on-premises servers and our Azure workloads?

Mostly no. The categories were designed for different starting points. Azure Site Recovery covers both Azure-native and on-prem to Azure. The appliance-based BCDR products are typically on-prem first, with limited cloud-native coverage. If your workload split is meaningful in both directions, expect to run two products. Our Melbourne cloud services page has more on hybrid architecture.

Cloud migration is the IT category where buyer disappointment is most common. The phrase covers projects from a five-day SharePoint setup to a two-year replatforming. Partners range from competent boutiques to outfits with junior consultants who will learn on your bill. Picking the wrong one locks in operational pain for five years.

This is a buyer’s guide written from the engineering side of the table. We will define what cloud migration services actually mean for an Australian SME in 2026 (mostly file server to SharePoint and OneDrive, on-prem Active Directory to Entra ID, and on-prem SQL or line-of-business systems to Azure). We will cover the three pricing models you will see and which one fits your situation. We will name the lift-and-shift trap that costs SMEs more in year three than the original project cost. And we will give you the 12 questions to ask a prospective migration partner before you sign anything.

TechAssist has been running migrations for Melbourne SMEs since we were founded in 2014. Our cloud services Melbourne team has migrated firms ranging from 8 to 250 staff, across professional services, manufacturing, healthcare, and not-for-profit. We have 13 Australian engineers, two offices (Tecoma and 575 Bourke St CBD), a 24/7 NOC, and per-user fixed monthly pricing for the run state after the migration. The engineering bias in this guide is real but the recommendations are the same we give clients we end up not working with.

What “Cloud Migration Services” Actually Means in 2026

The term has been used loosely for so long it has lost meaning. Let us define it concretely. For an Australian SME in 2026, “cloud migration” almost always means one or more of the following workstreams.

File server to SharePoint and OneDrive. This is the bread-and-butter SME migration. An on-premise file server (often a Windows Server running 2016 or 2019 that is past end-of-life on hardware) is being retired, and the file shares are being moved to SharePoint Online document libraries plus OneDrive for individual user files. The work is more nuanced than it sounds: permissions need to be modelled cleanly, mapped drive habits need to be transitioned, and the file structure usually needs to be restructured at the same time because the on-prem structure has accumulated 15 years of cruft.

On-premise Active Directory to Entra ID. The identity layer migration. Moving from a Windows Server domain controller to Entra ID as the primary identity provider, with hybrid join or full cloud join for Windows endpoints. This is the foundation for conditional access, device compliance, and most of the modern security controls. It is also the migration that quietly breaks the most legacy line-of-business applications, so the discovery work needs to be thorough.

On-premise SQL or line-of-business system to Azure. The infrastructure-as-a-service or platform-as-a-service migration. Moving a database or LOB application from on-premise servers to Azure SQL, Azure VMs, or App Service. This is where the lift-and-shift trap lives, and we will talk about it shortly.

Email migration. Moving from on-prem Exchange or a third-party mail provider to Exchange Online. This is increasingly a small workstream because most SMEs already moved email to the cloud years ago, but it still comes up for late-mover firms and for post-acquisition consolidation work.

Backup re-platforming. Moving from on-prem backup appliances to cloud-native or hybrid backup services that protect both on-prem and cloud workloads. This often gets bundled into the migration scope because the existing backup tool does not protect the new cloud workloads, and trying to bolt it on later costs more than rebuilding the backup strategy properly. See our backup and disaster recovery Melbourne 2026 guide for the broader picture.

For a typical Melbourne SME migration, two or three of these workstreams are bundled into a single engagement, with the file server and Entra ID work usually being the core, and the SQL or LOB workstream being the optional but heavier component.

The Three Pricing Models

The pricing model a partner offers tells you a lot about how they run projects. There are three common shapes for cloud migration engagements in the Australian SME market.

The honest take on which to choose: hybrid is the right answer for most Melbourne SMEs in the 30 to 100 staff range. Fixed-price discovery plus T&M build is the right answer when you have a legacy line-of-business application and the discovery phase needs to surface what the migration actually involves before anyone can credibly quote it. Full fixed price is the right answer when you have rigid budget approval processes that cannot tolerate any variance.

The model that should make you nervous: a low fixed price for an aggressive scope, where the partner is hoping to use change orders to recoup margin. This is the most common pattern of buyer disappointment we see. The kick-off feels great, the price feels right, and by week six you have approved $40,000 of change orders and the partner has rebuilt their margin on top of the original quote. The protection against this is a thorough discovery before the contract is signed.

The Lift-and-Shift Trap

This is the trap that costs Melbourne SMEs more in cloud cost over time than the migration itself. The partner takes your on-premise SQL Server, lifts it onto an Azure VM with the same specs, and shifts it to the cloud. The migration is fast, the bill at the end is low, and the project is declared a success.

The problem is what happens in year two and year three. The on-prem server was a one-time hardware capital cost amortised over five years. The Azure VM is a recurring operational cost forever. The specs that made sense on-prem (over-provisioned because hardware was hard to expand) are wasted in Azure because cloud workloads should be sized to actual load and scaled when needed. The result is a perpetual Azure bill that is two to four times what a properly designed cloud architecture would cost, with worse performance characteristics.

The fix is platform-as-a-service or refactoring during the migration, not after. Specifically: SQL Server should usually become Azure SQL Database (with elastic pool, or serverless tier for variable workloads), not an Azure VM running SQL Server. Windows Server file shares should become SharePoint and OneDrive, not Azure Files. Custom applications should be containerised or refactored to App Service where viable, not lifted onto VMs.

The reason partners default to lift-and-shift is that it is fast and low-risk for them. It avoids the architectural conversations that take time and require Azure expertise that not every partner has. It also positions them for a profitable optimisation engagement in year two, when the bill is hurting and you come back asking for help.

If you are evaluating a migration partner, the lift-and-shift conversation is the single best test of their depth. Ask them what they would do with your specific workloads. If the answer is “lift to Azure VMs first, optimise later,” that is a partner who is going to leave you paying the on-prem tax in Azure forever. Walk away. The right answer is “let us look at each workload and design the target architecture before we move, even if it takes longer up front.”

The 12 Questions to Ask Before You Sign

These are the questions we would ask if we were on the buyer side of a migration engagement. The answers will tell you more than any case study.

One. Show me the discovery deliverable from your last three SME migrations. The discovery document is the single best indicator of how seriously a partner takes scoping. If they cannot show you a sanitised example, or if the example is two pages of high-level boxes, they are not doing real discovery.

Two. How will you handle the Azure cost forecast for year one, year two, and year three? You want a projected monthly Azure bill at each milestone, with the assumptions stated. Partners who cannot do this are guessing on the cost side, and guessing means surprises.

Three. What is your specific approach to file permissions during the SharePoint migration? File permissions are where the migration’s hidden complexity lives. The right answer involves a permissions audit, a model for SharePoint sites and Teams, and a plan for the inevitable exceptions. The wrong answer is “we will replicate the existing structure.”

Four. How do you handle the legacy line-of-business application that does not support Entra ID? Every SME has at least one. The right answer involves identifying it during discovery, modelling the options (hybrid join, application proxy, replacement, retirement), and pricing the work accordingly. The wrong answer is “we will figure it out during the build.”

Five. What is your incident response if the migration goes sideways at 8pm on a cutover Saturday? You want to know who is on call, what their response time commitment is, and what the rollback procedure looks like. Cutover weekends are when migrations fail spectacularly, and you need to know there is a human and a plan when it happens.

Six. Who are the named engineers on this project, and what are their certifications? Not “our team has Azure certifications.” You want names, role descriptions, and which specific engineers will be doing the architecture and implementation. Partners who staff projects with rotating cast members give you inconsistent work quality.

Seven. What does your post-migration run state look like, and what is the handover process? Most migration disappointment is not during the migration. It is in the six months after, when something breaks and the partner is no longer engaged. You want clarity on the handover, the run state ownership, and the path to ongoing support.

Eight. Can you share a reference from a Melbourne SME of similar size and complexity, in the last 18 months? You want the reference to be both recent (so the partner is still operating at the same standard) and comparable (so the work has actually relevant similarity to yours). Generic enterprise references are not useful for SME engagements.

Nine. What happens if Azure costs come in higher than your forecast? Specifically: who eats the difference, and what is the process for re-evaluating the architecture? A partner who says “we will work with you to optimise” without committing to any responsibility is offloading the architectural risk onto you.

Ten. How do you handle change requests during the build? You want a written change request process with size thresholds, approval steps, and a commitment that changes below a certain dollar value will be absorbed rather than charged. Without this, change requests become the partner’s margin recovery mechanism.

Eleven. What is your approach to security during and after the migration? The migration is the perfect moment to uplift conditional access, MFA, application control, and Essential Eight alignment. A partner who treats security as out of scope for the migration is leaving the most valuable work on the table.

Twelve. Where will my data live geographically, and what is the data residency commitment? For most SMEs the answer is Azure Australia East or Australia Southeast, but you want this stated explicitly, with the specific workloads named. This matters more than buyers usually realise, especially for clients in government supply chain or regulated sectors.

The partner’s answers to these twelve questions will tell you who you are dealing with. The partner who hedges or generalises is the partner who will surprise you later. The partner who has specific, named, defensible answers is the partner worth talking to in detail.

A Sample Scope-of-Work Skeleton

Here is the structure of a sensible SOW for a Melbourne SME cloud migration. Adapt this for your situation. If the partner’s SOW is shorter or thinner than this, push back.

The SOW should be 25 to 50 pages for a typical mid-complexity SME migration. Less than that, the partner has not done the thinking. More than 80 pages, the partner is hiding complexity in volume.

A Melbourne Example: 65-Person Engineering Consultancy in Hawthorn

A 65-person mechanical and electrical engineering consultancy in Hawthorn engaged us in late 2024 for what they thought would be a SharePoint migration and turned into a broader cloud migration including identity, file shares, and an on-premise project management database.

The discovery surfaced more complexity than expected. The file server held about 14TB of project files including CAD models, which needed careful handling for SharePoint sync behaviour. The Active Directory had 11 years of accumulated permissions, roles, and group nesting that needed cleaning before any migration could be clean. The project management database was a SQL Server application with custom integrations to Outlook and to their cost-tracking spreadsheets that no one had documented in seven years.

The decision early in discovery: refactor where it materially reduces ongoing cost, lift-and-shift only where refactoring offered no value. SQL Server moved to Azure SQL Database (single database, with elastic pool option for future growth) instead of a VM. File shares moved to SharePoint with a redesigned site structure mapped to project workstreams rather than the old folder hierarchy. Identity moved to Entra ID with hybrid join during a transitional period, then fully cloud-joined endpoints by month six.

Timeline: 14 weeks from discovery start to final cutover, plus a 12-week post-migration support window. Cost: $148,000 fixed for the standard workstreams plus $34,000 T&M for the SQL refactor, against an internal budget envelope of $200,000. Azure run cost: $1,640 per month at steady state, against a forecast of $1,800. They are now on per-user fixed monthly managed service with us, with 24/7 NOC monitoring out of Tecoma and same-business-day on-site coverage when something needs hands on gear.

The lift-and-shift counterfactual: a partner who had simply lifted the SQL Server to an Azure VM would have charged less for the project (maybe $115,000 total) but the Azure run cost would have been roughly $3,400 per month due to the VM sizing and the SQL Server licensing on Azure. Over five years, the lift-and-shift would have cost the firm about $105,000 more in Azure spend, plus the future optimisation work to fix it. The architectural decision during the migration saved more than the migration cost over the asset lifetime.

Where TechAssist Sits in the Partner Landscape

We are honest about our positioning. We are not a Big Four consulting firm and we do not bid on $5m enterprise transformations. We are not a one-person operation working from a home office. We are a mid-market Melbourne MSP with 13 Australian engineers and the scale to handle SME migrations end-to-end while still being a partner you can call and get the principal engineer on the phone.

Our sweet spot is 30 to 250 staff Melbourne SMEs, professional services and skilled industries, where the migration needs to be done properly the first time, on a budget that is real but not unconstrained, with a transition into a managed service relationship afterwards. Our per-user fixed monthly pricing on the run state means we are not incentivised to leave you with brittle infrastructure that creates ongoing ticket volume.

We are Essential Eight aligned and ISO 27001 capable, which matters for clients moving into regulated sectors or pursuing certifications. We sub-15-minute respond to P1 incidents and provide same-business-day on-site coverage across Melbourne metro from our Tecoma office and our 575 Bourke St CBD office.

If our positioning does not fit your situation, that is fine. The questions in this guide will still serve you well with another partner. If it does fit, we are happy to run a discovery conversation. See our MSP Melbourne overview for the broader service description, our co-managed IT support page if you have an internal IT lead, and our managed IT services Melbourne page for the full service breakdown.

For vertical-specific context, see our law firms, manufacturers, and healthcare pages. For the broader provider selection framework, our how to choose an MSP Melbourne and top managed service providers Melbourne articles cover the ground.

The Six Red Flags That Should End the Conversation

If you see any of these during the sales process, the conversation should end. We have seen each of these cause migration disasters, and the partner’s behaviour during the sales cycle is the best predictor of how they will behave during the project.

One. They quote without discovery. A partner who gives you a fixed price for a migration without spending real time understanding your environment is either selling you a project they cannot deliver, or has priced in so much risk that you are overpaying.

Two. They cannot name the engineers. The salesperson is great. The case studies are slick. The actual delivery team is a mystery. This is the pattern where you find out, after signing, that the engineers are junior offshore staff or contractors with no continuity.

Three. The Azure cost forecast is “we will optimise after migration.” This is the lift-and-shift trap signalled in advance. Walk away.

Four. The change request process is “we will handle it.” No written process, no thresholds, no commitment. This will turn into endless change orders during the build.

Five. They will not provide a Melbourne SME reference of comparable scale. Generic references and enterprise references are not useful. If they cannot point you to a comparable client in the last 18 months, they have not done the work at your level recently.

Six. They are uncomfortable when you ask about security uplift during the migration. The migration is the moment to fix conditional access, MFA, and application control. A partner who treats this as out of scope is missing the point of why most SMEs are migrating in the first place. Read our zero trust security model explained and cybersecurity services Melbourne resources for the security framing.

Frequently Asked Questions

How long does a typical SME cloud migration take?

For a 50-person business with a moderate-complexity stack (file server, on-prem AD, one or two LOB applications), the engagement runs 12 to 20 weeks from discovery to final cutover, plus 8 to 12 weeks of post-migration support. Smaller and simpler migrations can be done in 6 to 10 weeks. Larger and more complex migrations can run 6 to 9 months. Anyone promising a serious migration in 2 to 4 weeks is selling you a rushed project.

Can we keep our existing IT person and just engage a partner for the migration?

Yes, and this is a common pattern, but it requires clear scope boundaries. The partner runs the project, the internal IT person handles end-user support, change communication, and the on-the-ground coordination during cutover. Our co-managed IT support model is built for exactly this arrangement. The pattern that does not work is the internal person trying to “help” with the technical migration work in parallel, which creates accountability gaps.

What does an Azure bill for a 50-person SME look like at steady state?

Depends entirely on the architecture and what workloads you have moved. For a 50-person business that has migrated file shares to SharePoint, identity to Entra ID, and one moderate SQL workload to Azure SQL, the Azure-side bill is typically $800 to $2,200 per month at steady state. The Microsoft 365 licensing is separate and runs $30 to $50 per user per month depending on tier.

Is hybrid cloud (some workloads on-prem, some in Azure) still a sensible choice?

For some workloads, yes. Specifically: industrial control systems, very large file shares where bandwidth economics matter (some video production and CAD scenarios), and certain LOB applications with vendor support constraints. For most SME workloads, hybrid is a transitional state, not a destination. Plan to be fully in the cloud within three years of starting the migration, or you will end up paying for the worst of both worlds.

What about Microsoft 365 Copilot during the migration?

Deploy after the migration, not during. The Copilot value comes from clean SharePoint structure, properly permissioned document libraries, and a tenant that has been hardened. Trying to roll out Copilot before the migration is finished produces poor user experience because Copilot is searching across the messy interim state.

How do we make sure we are not locked into the partner after the migration?

This is the right question to ask before signing. The protections are documentation (you should own all architecture documentation, including admin credentials and root-of-trust certificates), portable architecture (avoid partner-specific tooling for the run state), and a clean handover process. Our run-state pricing is per-user fixed monthly with no lock-in clause, and the architecture we deploy is standard Microsoft and Azure constructs that any competent partner can take over if you ever decide to move. Reach our team via the contact page for a discovery conversation.

Most cost-of-breach articles quote the IBM global average of 4.45 million US dollars. That number is useless if you run a 40-person professional services firm in Melbourne. It is calculated across global enterprises and tells you almost nothing about what a real incident costs an Australian SME.

This article does the opposite. It walks through a composite case study, anonymised but with real numbers from incidents we have helped respond to in late 2025, of a Melbourne professional services SME hit by a phishing-led business email compromise that escalated into a partial ransomware event. Line by line. Every number traceable to a real invoice, productivity calculation, or insurance excess. By the end you will have a defensible cost-of-incident model you can take to your board.

TechAssist has been responding to incidents like this since we were founded in 2014. Our cybersecurity services Melbourne team has worked on enough breaches across the Melbourne metro to know that the line-by-line numbers are remarkably consistent across firms of similar size. The variability is in the tail (insurance, customer churn, vendor questionnaires), and the tail is bigger than people expect.

The Case: A Hawthorn Professional Services Firm

The composite firm is 42 staff. Professional services, business advisory. Office in Hawthorn. Average revenue per consultant is $380,000 per year. Average gross margin around 55 percent. They had Microsoft 365 Business Standard (note: not Premium), a basic backup tool, MFA enabled but not enforced through conditional access, and a flat network with no segmentation. They had no formal incident response retainer, no tabletop exercises, and no cyber insurance until six months before the incident, when their bank required it as a condition of a working capital facility.

This is a deliberately realistic baseline. It is the security posture we see in roughly 30 to 40 percent of mid-market Melbourne firms when we first engage. Not abysmal, not great. Compliance with the obvious basics, gaps in the less-obvious depth.

The incident timeline: a senior consultant clicked a phishing link on a Wednesday afternoon, entered Microsoft 365 credentials into a credential-harvesting page, and the attacker logged into her mailbox at 4:47pm Melbourne time. By the time the consultant noticed something was off (Thursday morning), the attacker had set up inbox forwarding rules, created an OAuth app with mailbox-read permissions for persistence, and identified a finance team payment workflow they could exploit. Over the next four days, the attacker conducted classic business email compromise activities while also deploying ransomware on a file server the consultant had access to via mapped network drive.

The ransomware did not encrypt the entire estate. It encrypted approximately 40 percent of the file server contents, which included the active client engagement directory. The Microsoft 365 mailboxes and SharePoint were not encrypted but were exfiltrated, with evidence of approximately 12GB of data taken to an external server before the attacker was kicked out.

Line-by-Line: The Direct Costs

These are the invoices that hit the firm’s accounts payable system in the 90 days following the incident.

These are the invoices. They are the part most articles cover. They are also, in our experience, only about 35 to 45 percent of the actual total cost of the incident. The bigger numbers are the indirect costs, which we will get to next.

Line-by-Line: The Productivity and Revenue Losses

The firm was substantially offline for nine business days. Full operations did not resume for fourteen business days. Email was down for four days during the cleanup. The shared file environment was down or partially down for seven days. The active client engagement directory took the longest to fully restore because some of the data required reconstruction from local copies, email attachments, and supplier records.

Here is what the productivity loss looked like.

This is where the cost actually lives. The productivity loss is bigger than every invoice combined. And the only way to avoid this number is to maintain operations during the incident, which requires segmentation (so the incident does not take everything), backups that actually work (not just exist), and an incident response plan that has been rehearsed so the firm can keep working in a degraded mode while specialists clean up.

Note the calculation method. We are not double-counting. The 40 percent efficiency loss accounts for the fact that some work could continue on local copies, mobile devices, and via personal email. It is not a full revenue loss; it is the proportion of consultant time that was actually unproductive during the disruption period. For a fully air-gapped firm with no degraded-mode capability, this number would have been closer to $200,000.

The Indirect Costs: Where the Tail Really Hurts

The direct and productivity costs are large. The indirect costs are where the real long-term damage shows up, and these are the numbers boards consistently underestimate.

Customer churn. Two of the firm’s clients ended their engagement within four months of the incident. One cited the incident directly. The other did not, but the timing was clear. Combined annual revenue from those two clients: $340,000. Even attributing only 50 percent of the loss to the incident (because both clients had other contributing factors), the cost is $170,000 in lost annual revenue, or roughly $93,500 in gross margin in the first year. The two-year tail is materially worse.

Cyber insurance premium uplift. The firm’s cyber insurance premium at renewal increased from $11,400 per year to $34,800 per year, with a higher excess, more exclusions, and a requirement to demonstrate ongoing security controls (a quarterly attestation). Across a five-year window before they can credibly negotiate back down, that is roughly $117,000 in additional insurance cost.

Vendor security questionnaires. This is the cost that surprises most firms. Every existing enterprise client (and they had four) requested a detailed security questionnaire within three months of the incident becoming known. Each questionnaire required 8 to 14 hours of senior engineering time to complete, plus partner review and signoff. New business pursuits were paused for four months while they rebuilt their security posture sufficiently to credibly respond to procurement processes. We estimated the 14-month tail of vendor questionnaires and rebuilt pursuit activity at roughly $48,000 of internal time and $35,000 of opportunity cost from delayed new business.

Brand and recruitment impact. Harder to quantify. The firm reported two senior consultant hires falling through after the candidates raised the incident in second-round conversations. The estimated cost of the delayed hires and the additional recruitment spend was around $22,000.

The Total: A Real Number

Direct costs: $163,800. Productivity and revenue losses: $176,500. Indirect costs: $315,500. Total cost of the incident over the 14-month tail: $655,800.

That number, $655,800, is the realistic cost of a phishing-led BEC and partial ransomware incident for a 42-person Melbourne professional services SME with the security posture we described. Not 4.45 million dollars. Not 100,000 dollars. Somewhere between half a million and a million Australian dollars, depending on customer churn and how cleanly the insurance claim is handled.

If you scale this for a smaller firm (say 20 staff with $5m revenue), the number scales down roughly proportionally, but not linearly because the fixed costs (legal, IR, forensics) compress less. A similar incident at a 20-person firm typically lands between $300,000 and $500,000. For a 100-person firm, similar incidents land between $1.2 million and $2.5 million.

What Cyber Insurance Did and Did Not Cover

Cyber insurance is genuinely useful but is not a substitute for prevention. The Hawthorn firm’s policy covered most of the incident response retainer, forensics, legal counsel, and notification costs (about $99,000 of the first-party costs above the $25,000 excess). It did not cover the productivity loss, the customer churn, the premium uplift, or the indirect business impact.

The lesson: cyber insurance covers the bill from external responders. It does not cover the cost of being offline. It does not pay your consultants while they cannot work. It does not retain clients who have lost confidence. Insurance is a backstop for the invoiced costs. The productivity and tail costs are yours either way.

A second lesson: the insurer required, as part of claim acceptance, evidence of the controls the firm had attested to at policy inception. Their attestation said MFA was enforced on all users. In reality MFA was enabled but not enforced through conditional access, and the specific consultant whose credentials were compromised had MFA disabled via a legacy authentication grandfather clause. The claim was paid, but the next year’s renewal was tougher because the discrepancy was visible. Be careful what you attest to. Insurers will check.

What Would Have Prevented This Incident

Almost all of it was preventable, and almost none of the preventative controls were expensive relative to the incident cost. Here are the specific controls that would have prevented or substantially mitigated each phase.

The credential phishing would have been mitigated by phishing-resistant MFA (a hardware token or platform authenticator) instead of SMS or push notification MFA. Hardware tokens cost about $80 each. Platform authenticators (Windows Hello, Face ID) are free.

The credential theft, if MFA had been bypassed via a session-token phishing attack, would have been further mitigated by conditional access policies requiring a compliant device. The attacker’s session would have failed the device compliance check.

The OAuth app persistence would have been blocked by Microsoft 365’s Defender for Office 365 default policies (which block unverified app consent for users) and by an admin policy disabling user consent to apps without admin approval.

The lateral movement to the file server would have been mitigated by network segmentation (the consultant’s laptop should not have had unfiltered SMB access to the file server) and by application control (the ransomware payload should not have executed on the file server).

The ransomware impact would have been minimised by immutable backups with shorter recovery time objectives. The firm’s backup tool was working but the recovery process took four days because they had never tested it under realistic load.

The data exfiltration would have been detectable, and potentially preventable, by SharePoint download volume alerting and by data loss prevention policies on sensitive document libraries.

None of those controls is expensive. Microsoft 365 Business Premium (which includes most of them) costs about $36 per user per month, roughly $18,000 per year for the 42-person firm. The incident cost was $655,800. The math does not require a spreadsheet.

For the framework view, our zero trust security model explained guide covers how these controls fit together. For the backup and recovery side specifically, see our backup and disaster recovery Melbourne 2026 guide.

What Got Done in the Six Months After

The firm engaged us for remediation about three weeks into the incident response (their existing IT provider was not equipped to run incident response). Over the six months following the incident, the security posture was substantially rebuilt. Here is the rough sequence and cost.

The remediation cost less than the incident cost by a factor of five. If the same investment had been made before the incident, the incident would either not have happened, or would have been contained at a cost roughly an order of magnitude smaller.

The firm is now aligned with Essential Eight Maturity Level Two on most controls and is targeting Maturity Level Three for the controls that matter most to their client base. They moved to managed IT services Melbourne with us under per-user fixed monthly pricing, which gave them predictable costs and 24/7 NOC coverage out of our Tecoma office. P1 incidents are responded to in under 15 minutes, and same-business-day on-site coverage across Melbourne metro is the standard SLA.

Lessons for Boards and Owners

If you read nothing else from this article, read this section. These are the takeaways for non-technical decision-makers.

The IBM global average is irrelevant. Your number is between three and ten times your annual cybersecurity budget, and the multiplier is higher the worse your starting posture is. Calculate your number based on your headcount, your revenue per head, your billable model, and your client base.

The invoice is the smallest part. Productivity loss and indirect cost are 60 to 70 percent of the real total. Reducing the incident cost means reducing time-to-recovery and reducing customer impact, not just having someone to call when it happens.

Cyber insurance is necessary but not sufficient. It pays the bills from external responders. It does not pay your staff while they cannot work, and it does not prevent customer churn.

The controls that matter most are not expensive. Microsoft 365 Business Premium, conditional access, MFA enforcement, network segmentation, immutable backups, and application control collectively cost less than 5 percent of the realistic incident cost for an SME of this size.

Your client base will assess your security posture after an incident, and possibly before. If you serve enterprise clients, expect vendor questionnaires. If you serve government, expect IRAP-adjacent assessments. The post-incident scramble to answer questionnaires you should have answered years ago is one of the bigger hidden costs.

For the broader buyer’s guide on getting the right partner in place, see how to choose an MSP Melbourne and our top managed service providers Melbourne review. Privacy obligations are covered in our Australian Privacy Act for SMBs guide.

Frequently Asked Questions

How long does an incident response engagement typically take?

The intense phase is two to three weeks. Containment is days one to three. Forensics and scoping is the first ten days. Remediation continues for one to three months depending on the depth of the cleanup required. The notification and regulatory tail can run six to nine months. The vendor questionnaire and customer trust tail runs twelve to eighteen months.

Does paying the ransom make sense?

Almost never. In this case the firm did not pay because backups, while slow to restore, were intact. In cases where backups are not viable, paying the ransom is a partial gamble even with reputable negotiation specialists, and the legal and reputational ramifications are significant. The Australian Government discourages ransom payment and is moving toward mandatory reporting of payments. Our advice is to invest in recovery capability so paying is not on the table.

What is the single highest-leverage control to deploy first?

MFA enforcement with conditional access for every user. It is the single control that would have prevented the largest proportion of the incidents we have responded to over the last three years. Specifically: MFA enforced at the conditional access layer (not just enabled), with phishing-resistant methods (passkeys, platform authenticators, or hardware tokens) for at least admin accounts and high-value users.

Do I need a 24/7 SOC?

For most SMEs, no. A managed service provider with 24/7 NOC monitoring and a documented escalation path to an incident response specialist covers the same risk at a fraction of the cost of a dedicated SOC. We provide this as part of our managed service from our Tecoma NOC. Once you exceed 200 staff or move into highly regulated industries, the calculus changes.

How often should we run tabletop exercises?

Quarterly for the first year after starting a security programme. Twice yearly thereafter. The first tabletop usually exposes more gaps than the actual control review did, because it surfaces decision-making issues that controls do not address (who calls the lawyer, who briefs the board, who talks to clients).

Where do I start if my security posture is similar to the case study firm?

Start with an assessment. Not a vendor pitch. An honest evaluation of where your gaps are, what they would cost to remediate, and what they would cost if exploited. We do this for Melbourne SMEs out of our Tecoma office and our 575 Bourke St CBD office. Reach the team via the contact page and we will run the assessment with you.

Switching MSPs is a documentation problem dressed up as a technical one. Get the paperwork right in the first three weeks and the cutover is uneventful. Get it wrong and you’ll spend month two chasing passwords. This is the 90-day playbook we use when onboarding Melbourne SMEs leaving another provider.

The post assumes you’ve already made the call. You’re not weighing up how to choose an MSP in Melbourne — you’ve chosen. What you need now is execution: a sequence of decisions and handover tasks that gets you out of the old contract cleanly and into the new one with your data, your tenant control and your sanity intact.

The three decisions you settle before day zero

Most failed MSP migrations fail before they start, because the incoming provider was handed a vague brief and the outgoing one was given a vague deadline. Settle these three things in writing before the 90-day clock begins.

1. What’s in scope and what isn’t

Re-scope from scratch. Don’t inherit your old MSP’s scope document — it was almost certainly written to suit their staffing, not your needs. Walk through every endpoint, every server, every SaaS tenant, every printer, every meeting room, every shadow-IT app the finance team has been quietly paying for, and decide: managed, co-managed, or out-of-scope.

The honest answer for most Melbourne SMEs sits somewhere between fully managed and co-managed IT support, where the internal champion keeps the institutional knowledge and the MSP handles the heavy lifting. Decide which model you want before you sign, because it changes the SLA, the pricing and the documentation burden on day one.

2. The transition window

Pick the date the outgoing MSP’s responsibility ends, and pick it carefully. Don’t end it on a Friday. Don’t end it the day before a board meeting, end-of-month payroll, or a public holiday long weekend. We strongly prefer mid-week, mid-month cutovers — usually a Wednesday — so there’s time on either side to fix anything weird without burning a weekend.

Build a 30-day parallel-running window into the contract if you can. Some outgoing MSPs will fight this; their commercial incentive is to be gone the moment the notice period ends. Push back. A parallel period — where they still answer P1 tickets while the new provider takes over documentation and tooling — is the single biggest predictor of a clean switch.

3. Who owns the data, the tenant, and the licences

This is the conversation that exposes the bad MSPs. If your current provider’s name is on your Microsoft 365 tenant as the global admin owner, on your domain registrar account, on your backup vendor’s portal, or on your CSP partner record — you have a problem, and you need to fix it before you give notice. Not after.

Your business should own:

• The Microsoft 365 tenant, with at least two break-glass global admin accounts that belong to your staff, not the MSP
• The domain registrar account (and DNS, if it’s separate)
• Any CSP relationship and the licences attached to it — these can be transferred between partners but only if the outgoing one cooperates
• Your backup data and the keys/credentials to access it directly
• Firewall and switch admin accounts, with documented passwords held by you

If you can’t tick all of those today, the first month of your 90-day plan is going to be about clawing them back. That’s normal. It just needs to be planned for.

Days 0-30: onboarding, documentation, and the quiet panic

The first month is unglamorous. It’s spreadsheets, screenshots, audit logs and asset lists. Resist the temptation to start changing things — the new MSP’s job in month one is to learn your environment, not improve it.

What to demand from the outgoing MSP

Send this list in writing on day one. Give them fourteen days. Escalate to their account manager on day fifteen.

If the outgoing MSP refuses any of the above, you have a documentation problem and possibly a contract problem. Read your exit clause carefully — most decent MSP agreements include a transition cooperation obligation, even if it’s buried. If yours doesn’t, that’s a lesson for the new contract.

Vendor relationship transfers

Microsoft is the big one. If your licences sit under the outgoing MSP’s CSP tenant, you have three options: transfer the CSP relationship to your new MSP (cleanest, but needs both providers to cooperate), move to direct billing with Microsoft (clean break, but you lose any CSP discount and pick up admin overhead), or run a fresh CSP relationship in parallel and migrate users across. Most of our incoming clients choose option one. It takes about ten business days when both sides play ball, and four weeks of pain when they don’t.

Cisco Meraki, Datto, Veeam, NinjaOne, Ahsay, SentinelOne, Huntress — anything with a partner portal — works the same way. Each vendor has its own re-assignment process, each takes a different amount of time, and each one needs the outgoing partner’s sign-off. Map every vendor relationship in week one. Start the transfer requests in week two. By week four, most should be done.

The “who do I call now?” comms plan

Your staff don’t care about your CSP transfer. They care about who picks up the phone when Outlook stops working. Two communications go out in the first week of the new MSP relationship:

Internal staff comms — short, plain, on a single page. New helpdesk email, new phone number, what counts as a P1 (and what to do about it after hours), and a one-line reassurance that nothing else is changing yet. Keep it under 200 words. Pin it in Teams. Print it for the front desk.

Vendor and partner comms — a separate note to your accountant, your auditor, your software vendors and your ISP, telling them who the new IT provider is and giving them updated contact details. Five emails, fifteen minutes, saves a week of confused calls in month two.

At TechAssist, this is the part we drive hardest in week one. Our managed IT services onboarding kicks off with a comms pack the client can send out the same afternoon they sign — because the technical handover takes weeks, but the staff experience changes the moment someone needs help.

Days 31-60: cutover, validation, and finding the lies

Month two is where the previous MSP’s documentation gets tested against reality. It’s also where you migrate the systems they were responsible for — backups, monitoring, ticketing, security tooling — and where things go wrong if anyone rushed month one.

Backup and DR migration

Don’t decommission the old backup until the new one has completed a full successful cycle and a test restore. That sounds obvious. It is regularly ignored.

The order we use:

1. New backup platform deployed and configured in parallel — Veeam, Datto, Ahsay, whatever the new MSP standardises on. Old backups continue running untouched.
2. First full backup completes successfully on the new platform. Verify the job logs, not just the dashboard summary.
3. Test restore performed — not a “we restored a file” test, an actual rebuild of a representative VM or mailbox to an isolated environment, with the client present.
4. Second successful cycle.
5. Old backup retention frozen (don’t delete — freeze) for a minimum of 90 days after cutover. This is your safety net if a corruption is discovered later.
6. Old backup agents removed from production endpoints.

Do not skip the test restore step. We have seen handovers where the outgoing MSP’s backup dashboard was green every day for two years and nothing was actually being captured beyond the C: drive. The only way to find that out is to try to restore something that matters.

Monitoring and ticketing platform switch

The new RMM agent goes on every endpoint in month two. So does the new ticketing system’s email connector. The old RMM and ticketing email stay live in parallel until day 60, then come down.

Two specific gotchas. First, antivirus and EDR conflicts — running SentinelOne alongside Defender for Business alongside the outgoing MSP’s Webroot deployment will cause genuine performance issues and false positives. Plan the security tool swap as a single coordinated change, not a gradual rollout. Second, RMM agent collisions on shared resources, especially scheduled tasks and Windows Update behaviour. Audit scheduled tasks after the new agent is in place; you’ll usually find three or four orphaned jobs from the previous provider that nobody removed.

Security baseline reassessment

Month two is the right time to ask “is the security posture we inherited actually any good?” — and to answer it honestly. Run a fresh baseline: MFA coverage across all accounts (not just users — service accounts, break-glass, admin), conditional access policies, Defender for Office 365 settings, Entra ID logs, privileged role assignments, and external sharing settings on SharePoint and OneDrive.

It is not unusual to find that the outgoing MSP had MFA enforced for staff but not for the three service accounts that authenticate to line-of-business apps. It’s almost universal to find at least one privileged role assignment that should have been removed when someone left the business two years ago. Fix these before they bite you.

A concrete example

A South Yarra logistics firm — around 45 staff, two warehouses, a fleet of about thirty vehicles — switched to us in Q3 2025 after their previous MSP missed two P1 outages in a single quarter. The pre-switch audit found that the firm’s Microsoft 365 tenant had the outgoing MSP listed as the primary CSP partner with sole global admin rights, no break-glass accounts owned by the client, and the domain registrar account was registered to a personal Gmail address belonging to the outgoing MSP’s former tech lead, who had left that business eighteen months earlier.

Reclaiming the tenant took twelve business days and a Microsoft support case. Reclaiming the domain took a further three weeks and required a notarised letter of authority. None of this was technically complex. All of it was the documentation problem this post keeps banging on about. By day 60 the firm was fully migrated, with a backup regime that actually included their warehouse management database (the previous one did not), and a per-user fixed monthly fee they could budget against. The first three months of tickets came in under our standard sub-15-minute P1 response, and the on-site work — including a Wi-Fi controller swap at the Port Melbourne warehouse — was handled same-business-day from our Tecoma NOC.

Days 61-90: stabilise, verify, and close the door

The final month is about proving the new arrangement works and shutting down the old one for good.

SLA verification with real tickets

By day 60 you should have enough ticket history with the new MSP to verify what they promised against what they’re actually delivering. Run a report. Not the MSP’s report — your own pivot of the ticket data, exported. Look at:

• P1 response time, mean and 95th percentile (not just the average — averages hide the bad ones)
• P2 and P3 resolution time against SLA
• Tickets reopened within seven days (a proxy for “fixed it properly the first time”)
• After-hours ticket coverage, if you pay for it
• On-site response time for the tickets that needed it

If something’s off, raise it at the day-90 review, in writing, with the numbers. A good MSP will look at the same data and either explain it or fix it. A bad one will tell you the dashboard says everything’s fine.

Final removal of outgoing MSP access

Day 75 is the audit. Every system, every portal, every shared mailbox, every Teams channel, every PSA integration — does the outgoing MSP still have a way in? They almost always do. The common ones we find at this stage:

• An old Entra ID guest account still active
• A service principal or app registration created during their tenure with broad Graph permissions
• A VPN account that wasn’t disabled
• A shared admin email forwarder that still copies to their helpdesk
• RMM agent remnants on one or two endpoints that were offline during the rollout
• Their public IP still in your firewall allowlist for “remote support”

Close them all. Document who closed each one and when. This isn’t paranoia — it’s basic hygiene and it’s increasingly a requirement of cyber insurance renewals.

The post-mortem with the new MSP

Day 90 isn’t a celebration, it’s a review meeting. The honest version of this conversation includes “what wasn’t documented that we wish had been,” “what surprised us in the environment,” and “what we’d do differently if we did this again.” If your new MSP can’t have that conversation, they’re not the right MSP. If you don’t have it, you’ll repeat the same mistakes in three years when you switch again.

Red flags from outgoing MSPs

Some MSP handovers go badly because the outgoing provider is genuinely overstretched. Some go badly because they’re being hostile. It helps to know which one you’re dealing with.

The single best defence against a hostile handover is having owned your own tenant from day one. If you’ve already given notice and you don’t own it, the first phone call is to Microsoft (or the relevant vendor) to start the partner-of-record change, not to the outgoing MSP.

What a good incoming MSP actually does in the first 90 days

To set expectations on the other side of the table — here’s what we do when a Melbourne SME signs with us. We’ve been doing this since 2014 and we’ve refined the playbook through several dozen migrations across industries from logistics to professional services to manufacturing.

Week one is documentation and access. Our onboarding engineer (not a salesperson) sits with the client’s internal champion, sometimes at our Tecoma office, sometimes at our 575 Bourke Street CBD office, sometimes on-site at the client. We work through the artefact checklist above and we don’t leave the room until either we have the documents or we have a written commitment from the outgoing MSP on when we’ll have them.

Week two and three is monitoring and tooling deployment in parallel — we don’t switch off anything the outgoing MSP is doing yet. Our NOC at Tecoma picks up alerting; the outgoing MSP’s RMM keeps running until day 30.

Week four is the comms switch. The client’s staff get the new helpdesk details. Our sub-15-minute P1 response and same-business-day on-site for Melbourne metro becomes the standard. Per-user fixed monthly pricing kicks in — no hourly billing for anything that was in the agreed scope, which removes the awkward “should I log this ticket?” decision for the client’s staff.

Weeks five through eight are the technical migrations — backups, security tooling, the harder vendor transfers. Weeks nine through twelve are stabilisation and the day-90 review.

That’s it. It’s not glamorous. It works because the order is right and because the people doing it have done it before. Our thirteen engineers are all Australian-employed and most of them have been with us long enough to have run this playbook a dozen times. If you’re comparing providers and want a longer reference list, our writeup on the top managed service providers in Melbourne covers what to look for in this stage of the conversation.

FAQ

How long does switching MSPs actually take?

From signed contract to fully decommissioned previous provider, plan for 90 days. The technical work is usually done in 45-60 days; the remaining time is SLA verification, security baseline review, and the final access cleanup. Smaller environments (under 25 staff, no on-premises servers, clean Microsoft 365 tenant) can be done in 45 days. Larger or more complex environments, or anywhere with a hostile outgoing provider, can stretch to 120 days.

Will my staff be without IT support during the switch?

No — not if it’s run properly. The whole point of the parallel-running window in the first 30 days is that the outgoing MSP keeps handling P1 tickets while the incoming MSP takes over documentation and tooling. By day 30 the new provider is taking everything. There should be no period where nobody is on the hook.

What happens if the outgoing MSP won’t hand over passwords or admin access?

Read your contract first — most MSP agreements include a transition cooperation clause, and a written reminder of it usually unlocks the handover within a week. If that doesn’t work, the vendors themselves (Microsoft, your domain registrar, your backup vendor) have partner-of-record change processes that don’t require the outgoing MSP’s consent, though they take longer. As a last resort, a letter from your solicitor referencing the contract terms is usually sufficient. We’ve never had to go further than that.

Do I have to migrate to my new MSP’s preferred tools?

Mostly, yes — and that’s usually fine. MSPs deliver SLAs through standardised tooling; if every client runs different backup, monitoring and security stacks, the response times suffer and the cost goes up. The exception is line-of-business software, which obviously stays where it is. If your new MSP insists on swapping out a working line-of-business system as part of onboarding, push back hard — that’s a separate project.

Can I keep some IT in-house and outsource the rest?

Yes, and for a lot of Melbourne SMEs this is the right model. Co-managed arrangements where an internal IT person or small team handles day-to-day requests and strategic projects, and the MSP handles the NOC, helpdesk overflow, after-hours and specialist work, tend to give the best outcome per dollar spent. The 90-day playbook above works the same way; the scope conversation in the pre-switch phase is just more detailed.

What’s a reasonable price to pay during the transition?

You’ll likely pay both MSPs for the first 30-45 days — the old one on the existing contract, the new one on a reduced onboarding fee or a ramped-up monthly. Budget for it. Trying to avoid the overlap by ending the old contract early is where most failed migrations start. The overlap cost is small compared to the cost of a botched cutover.

How do I know if the new MSP is actually any better?

Real ticket data at day 90. Not testimonials, not the sales pitch, not the dashboard the MSP shows you — your own export of the ticket history, with response and resolution times against the SLA you signed. If the numbers are good, you’re in the right place. If they’re not, you have the conversation early, when it’s still fixable.

If you’re partway through this decision and want a second opinion on the pre-switch audit — particularly the tenant ownership and vendor relationship pieces, which are where the worst surprises live — get in touch. An hour on the phone before you give notice saves a fortnight in month two.

When your accounting server falls over at 9:47am on a Tuesday, the postcode on your MSP’s business card suddenly matters a great deal. The difference between an engineer arriving at 10:35am and one arriving at 1:15pm is the difference between a small disruption and half a day of staff sitting around being paid to do nothing.

This is the part of choosing a managed IT provider that almost nobody talks about properly. Everyone benchmarks on price, ticket SLAs, certifications and the shiny dashboard in the sales deck. Very few prospects ask the question that actually predicts how their first bad day will go: where does your nearest engineer physically sit, and how long does it take them to be standing in my server room?

I run engineering at a Melbourne MSP. We’ve deliberately built around two offices — one in Tecoma at the foot of the Dandenongs, one at 575 Bourke Street in the CBD — and the reason for that setup is the subject of this post. Let’s get into why MSP office location in Melbourne is a real operational issue, not a marketing detail, and how to read a provider’s address like the signal it actually is.

The geography problem nobody costs out properly

Melbourne is not one city when it comes to drive times. It’s at least three. A van leaving Cremorne at 8:30am can be in Richmond in twelve minutes and in Ringwood in an hour and twenty. The same van leaving Tecoma at the same time is in Ringwood in twenty-five minutes and the CBD in just over an hour — if the Burnley Tunnel is behaving, which it often isn’t.

Most MSPs draw a circle on a map labelled “service area” and tell you they cover all of metropolitan Melbourne. Technically true. Operationally meaningless. What you actually want to know is: when something is on fire at my office in Box Hill, where does the engineer leave from, what time of day is it, and how does that translate to wheels-on-the-ground?

Here’s the rough drive-time reality for a typical weekday morning in Melbourne. These aren’t Google’s optimistic estimates — they’re what our engineers actually experience.

That last row is not a joke. A surprising number of “Melbourne IT support” providers are actually Sydney-headquartered operations with a serviced-office mail drop in Southbank and a contractor network they call when something needs hands on hardware. If your business is in Glen Waverley and your provider’s nearest actual employee is in Parramatta, your same-day on-site is going to be whatever the cheapest contractor on Airtasker is doing this afternoon.

What “same-day on-site” actually means

Every MSP website promises same-day on-site response for Melbourne metro. Read that promise carefully. Some of them mean “a technician will be on site before close of business if you log the ticket before 11am, weather and traffic permitting, subject to availability.” Some of them mean what we mean, which is: if the ticket is logged before about 2pm and the site is in the metro, an engineer is in your car park that afternoon.

The reason we can promise the second version is geography. Our Tecoma office covers the entire eastern corridor — Ferntree Gully, Boronia, Bayswater, Ringwood, Croydon, Lilydale, Mooroolbark, all the way out to the Yarra Valley — without anyone fighting the Monash. The CBD office covers the inner ring — Richmond, South Yarra, Cremorne, Collingwood, Brunswick, Hawthorn, Camberwell — without anyone fighting the freeway. Between the two offices, almost every postcode in Melbourne sits inside a 45-minute drive from at least one of our engineers, off-peak. That’s the operating envelope our managed IT services in Melbourne are built around, and it’s why our sub-15-minute response on P1 critical incidents actually holds up in practice rather than just in the contract.

An MSP working out of a single CBD office will quote you the same same-day promise, and they’ll usually keep it for inner-suburb clients. Out at Ringwood or Frankston, that promise quietly degrades into “we’ll get someone out tomorrow morning” the third or fourth time it’s tested. The contract doesn’t change. The reality does.

The case for a CBD office (when you actually need one)

I’m not going to pretend an outer-east-only MSP is always the right answer. There are very real reasons to want a provider with a genuine CBD presence, and those reasons are mostly about your people, not theirs.

If your business is headquartered in the CBD or inner ring — a law firm in William Street, a fintech in Cremorne, a consultancy in South Yarra — your staff and your decision-makers don’t want to drive to Tecoma for a quarterly review meeting. They want to walk five minutes from their desk, sit in a meeting room near Southern Cross, do an hour on roadmap and security posture, and walk back. That’s a legitimate need and one of the reasons we maintain meeting space at 575 Bourke Street.

Inner-city clients also tend to need a different style of on-site work. The issues we see at a Hawthorn architecture practice are mostly user-facing: a partner’s laptop, a printer that’s lost its mind, a meeting room AV that won’t play with someone’s MacBook. These are walk-up jobs. Having an engineer who can take a tram and be at your front desk in twenty minutes, no parking fee, no van required, is genuinely more efficient than dispatching a vehicle from forty kilometres east.

Here’s where the CBD-only MSP makes sense:

• Your offices are all inside the inner ring (roughly Footscray to Hawthorn, Brunswick to St Kilda)
• Your on-site needs are mostly user support, not server/network/cabling work
• You don’t have warehouses, manufacturing sites or distribution centres in the outer suburbs
• Your senior team wants to meet face-to-face often, and they don’t want to leave the CBD to do it

If that describes your setup, a good inner-Melbourne MSP can absolutely look after you. Our IT support in Melbourne serves a lot of clients in exactly this profile.

The case for an outer-east office (when you actually need one)

Now flip it. Plenty of Melbourne businesses are headquartered or operationally based in the east — Box Hill, Doncaster, Ringwood, Bayswater, Knoxfield, Scoresby — or out toward Dandenong and the south-east industrial belt. For these clients, having an MSP whose nearest engineer is in the CBD is genuinely worse.

We worked with a logistics business in Dandenong a couple of years back, before they came across to us. Their previous provider was a well-known Melbourne MSP with a single Collins Street office. The contract promised four-hour on-site response. In practice, with the Monash being the Monash, every site visit became a half-day write-off for the engineer and a multi-hour wait for the client. The client was paying senior engineer rates for someone who spent forty per cent of their billable time in traffic. We took the account over, started running it out of Tecoma, and the average on-site arrival dropped from about three hours to under forty-five minutes. Same SLA on paper. Completely different lived experience.

The outer-east-only MSP makes sense when:

• Your business is in the eastern, south-eastern or outer-suburban belt
• You have physical infrastructure that needs hands on it — servers, network gear, structured cabling, factory floor PCs, warehouse barcode systems
• You don’t need anyone driving into the CBD to meet your team — your senior people are happy to meet at your office or at the MSP’s office in the east
• You want client parking that doesn’t cost $18 an hour (our Tecoma office has free off-street parking, which sounds trivial until you’ve tried to host a client meeting in Melbourne city)

For these clients, our IT support for the eastern suburbs is run end-to-end out of the Tecoma office, with engineers who actually live in the area. That last bit matters more than people realise, and we’ll come to it.

Why two offices is the honest answer for most mid-size businesses

Here’s the thing nobody in the MSP industry wants to say plainly: most Melbourne SMEs in the 20-150 staff range don’t fit neatly into either box. They have a head office in the inner ring and a warehouse in Bayswater. Or a CBD showroom and a manufacturing site in Dandenong. Or three sites scattered from Werribee to Glen Waverley because that’s where the property was available when they were growing.

For these clients, the right answer is a provider with real coverage on both sides of the city. Not a marketing claim of city-wide service, but actual engineers leaving from offices on both sides of the Monash. That’s the reasoning behind our two-office structure, and it’s not a coincidence that almost every multi-site client we’ve onboarded in the last few years has cited geography as one of the deciding factors.

The comparison looks something like this:

You’ll notice the two-office model wins or draws in every row. That’s not me being clever — it’s just that having a second office is mostly a cost the MSP absorbs to give the client optionality. For us, running both our CBD office at 575 Bourke Street and our Tecoma office means a 13-person engineering team can be deployed from whichever location makes sense, and clients aren’t paying for an hour of drive time on a thirty-minute job.

After-hours and on-call: where geography becomes brutal

Daytime drive times are one thing. The 2am call when a ransomware indicator fires on your file server is another.

After-hours support is the part of MSP work where the location of the engineer’s home — not the office — becomes the actual variable. An on-call engineer who lives in Belgrave can be at a client site in Ferntree Gully in eight minutes at 3am. An on-call engineer who lives in Footscray can’t, no matter what the SLA says, because they have to wake up, get dressed, get in a car, and drive across the city on roads that are mercifully empty but still finite.

This is the bit you can’t really fix with policy. You can only fix it by hiring engineers who live in the geographic spread your client base needs. Our team is deliberately mixed: some live in the eastern hills near the Tecoma office, some live in the inner north and west near the CBD office, a couple are in the south-east. That spread is the actual on-call coverage, not the rota on a wall.

When you’re vetting an MSP, the question to ask isn’t “do you offer 24/7 support?” — everyone says yes. The questions are: where do your on-call engineers live? Are they employees or third-party contractors? What’s the typical actual response time to a P1 after-hours incident in the last six months? If they can’t answer the first two without checking, that tells you something about how the after-hours service really works.

Parking, meeting rooms and the unglamorous logistics

This sounds trivial. It isn’t. When you visit your MSP — for a quarterly business review, a security workshop, a roadmap session — the experience of getting there sets the tone for the meeting.

If your provider’s only office is in the CBD, your visit means: book a park at Wilson’s for forty bucks, walk three blocks, sit in a borrowed meeting room on the eighteenth floor, watch the clock because your park expires at 2pm. Or take public transport in, lose ninety minutes of your day, and arrive slightly frazzled.

If your provider has an outer-east office with real parking, your visit means: drive in, park out front for free, walk into a meeting room that the MSP actually owns rather than rents by the hour. For clients based anywhere in the east, that’s a one-hour visit instead of a half-day excursion.

It also matters for the inverse — when the MSP visits you. An engineer dispatched from a CBD office to a client in Knoxfield is going to bill you for at least an hour of travel each way during peak. An engineer dispatched from Tecoma is going to bill twenty minutes. Over a year of on-site technical support visits, that’s not a rounding error — it’s thousands of dollars of avoidable travel time.

The Sydney-pretending-to-be-Melbourne problem

I touched on this earlier and want to come back to it, because it catches people out. There are a handful of larger MSPs operating in Australia where the head office, the engineering team, the NOC and the help desk are all in Sydney or Brisbane, and “Melbourne presence” means a sales rep with a Southbank address on her email signature.

You can usually spot this by reading the website carefully. Look for the office addresses (real street addresses, not just “Melbourne, VIC”), look for the team page with engineers whose LinkedIn says they live in Melbourne, and check who answers the phone when you call. If the receptionist says “thanks for calling [company], how can I direct your call?” without naming a city, and you can’t find a Melbourne-based engineer on staff, you’re dealing with a Sydney shop with a Melbourne mailbox.

That isn’t always disqualifying. For purely remote-managed services — cloud, M365, SOC monitoring, that kind of thing — geography genuinely doesn’t matter. But the moment your environment needs hands on hardware, or your team wants someone in the room, the cracks show up fast. Our team is thirteen engineers, all directly employed, all based in Melbourne. We don’t subcontract on-site work. That’s deliberate, and it’s one of the things you should be probing for when you talk to any provider.

What to actually ask when you’re evaluating an MSP

If you’re partway through choosing a new provider — or thinking about switching — here’s the location-related checklist I’d run through before signing anything. None of these questions are aggressive; they’re just specific enough that the answers tell you the truth.

1. Where is your nearest physical office to my main site, and what’s the actual address?
2. How many of your engineers live within thirty minutes of that office?
3. If we log a P1 ticket at 10am from my main site, who dispatches, from where, and what’s your last-six-months average?
4. For after-hours P1, where does the on-call engineer leave from?
5. If we need a face-to-face meeting at your office, where do we park and what does it cost?
6. Is on-site work done by your employees, or do you sub-contract it?
7. For multi-site clients, can you cover all sites from a single office, or do you have multiple offices we should know about?

You don’t need to grill the salesperson. Just ask, listen to whether the answers sound rehearsed or specific, and notice whether they can give you names and addresses or whether they retreat into language about service areas and coverage zones.

Where TechAssist sits in all this

To be straightforward about our own setup, because the post is about office location and we’d be dodging if we didn’t lay our cards down: TechAssist has been operating since 2014, has thirteen engineers all employed directly in Melbourne, and runs out of two offices — Tecoma (with free parking, covering the eastern corridor and outer east) and 575 Bourke Street in the CBD (covering the inner ring). We commit to sub-15-minute response on P1 critical incidents and same-business-day on-site for Melbourne metro, and the geography of the two offices is what makes those commitments actually work rather than just sound good.

That setup suits a particular kind of client: Melbourne-based SMEs, typically 20-150 staff, with at least some physical infrastructure or sites that need on-site attention, and senior people who don’t want to be playing geography roulette every time something breaks. If that sounds like your situation, our locations page has the addresses and direct numbers for both offices, or you can reach us on 1300 028 324.

Frequently asked questions

Does it really matter where my MSP’s office is if most support is remote?

For day-to-day helpdesk tickets — password resets, software issues, M365 administration — no, geography is largely irrelevant. Where it matters is the 5-10% of issues that need physical presence: hardware failures, network gear, on-site project work, staff inductions, quarterly reviews, and any kind of emergency where a remote session won’t cut it. Across a year, those incidents are where you find out whether your provider’s address is operationally real or just a line on the website.

Is a CBD-based MSP automatically worse for businesses in the outer suburbs?

Not automatically, but the maths is against them for anything that involves drive time. A good CBD-only MSP serving an eastern-suburbs client will lean heavily on remote support and book on-site visits in batches to amortise the travel. That works if your environment is straightforward. It starts to wear thin if you have frequent ad-hoc on-site needs, multi-site coverage, or after-hours requirements.

How do I know if an MSP is actually Melbourne-based or just claiming to be?

Look for a verifiable street address (not a serviced-office or virtual-office number), a team page with engineers whose LinkedIn profiles show Melbourne, and a local phone number that’s answered by a person rather than routed to a Sydney call centre. Ask the salesperson where the engineers who’d be assigned to your account physically work from. If the answer is vague, that’s the answer.

What’s the practical difference between a one-office and a two-office MSP for a multi-site client?

Travel time and dispatch flexibility. A two-office MSP can send the closest engineer to whichever of your sites has the issue, rather than having every job leave from the same address regardless of geography. For a client with a CBD head office and an outer-suburbs warehouse, that typically halves the average on-site arrival time across the year.

What if my business is entirely cloud-based and we don’t have a physical office?

Then office location matters a lot less, and you should weight the decision toward other factors: depth of cloud expertise, security maturity, response times on remote tickets, and cultural fit. The geographic question is really about hands-on-hardware work, so if you have none of that, it drops down the priority list.

The short version

The MSP industry doesn’t talk about office location much because, frankly, most providers don’t have a good story to tell about it. They cover everywhere on the map, which is the same as saying they cover nowhere properly. The honest answer is that geography is one of the strongest predictors of how an MSP relationship will actually feel once you’re past the sales cycle and into the day-to-day grind of running your business.

If you’re weighing up providers and want to talk through how the geography of your sites maps to the right kind of support model, get in touch via our contact page or call 1300 028 324. We’ll give you a straight answer — including, if it’s the right call, that you’d be better off with someone closer to where your business actually operates.