Azure Cost Creep: A FinOps Starter Guide for Melbourne SMEs

Azure costs for Melbourne SMEs grow 30 to 50% a year without anyone noticing. Enterprise FinOps assumes a $5 million cloud spend; this is the SME version, sized for the $50k to $500k reality. Eight quick wins, governance guardrails that stick, and the three traps that catch almost every business.

Why SME Azure spend creeps

It is rarely one decision. A pilot tenant becomes a production tenant. A test virtual machine becomes a forgotten orphan with a 1 TB premium SSD attached. Defender for Cloud gets enabled on a free trial, ends up on the Standard tier across every subscription, and nobody can find the off switch by the time the invoice arrives. The dev environment that was ‘just for two weeks’ is still running 18 months later because no one wants to be the person who turned it off.

We see the same pattern across our managed clients. A business signs up for Azure at $3,000 a month. Two years later it is $11,000 a month, the workloads have not materially expanded, and the CFO is asking the right question for the first time. By then the answer is harder than it would have been at $4,000.

FinOps as a published discipline (the FinOps Foundation maintains the framework, Microsoft has published its own opinionated version) assumes you have a cloud platform team, a financial analyst, and an executive sponsor. For a 60-staff Melbourne business with a quarter-million-dollar Azure footprint, that is overkill. The lite version below takes the parts of FinOps that apply at SME scale and ignores the rest. We have run this with clients across professional services in the CBD, manufacturers out around Dandenong, and not-for-profits across the eastern suburbs as part of our Melbourne cloud services work.

What ‘normal’ SME Azure spend looks like

Some benchmarks from our managed book, useful as sanity checks on whether your number is in the right zone.

If your number is materially above the band for your profile, there is almost certainly waste. If your number is materially below, either you are doing something genuinely clever or you have under-provisioned somewhere that will cause a production incident later.

The eight quick wins

Most SMEs can take 20 to 35% off their Azure bill in a fortnight of focused work, without changing anything about what the business does. The targets in order of effort-to-saving ratio:

1. Rightsize the virtual machines

The Azure Advisor and the Azure Migrate tools both flag VMs running well below their provisioned capacity. The reality is most SMEs have two or three D8s_v5 instances that were sized off a panicked guess at the start of a migration and have been running at 8% CPU ever since. Moving them down two or three sizes typically saves 60 to 75% of the per-VM cost. Validate with seven days of metrics first; do not just take Advisor’s word for it.

One client of ours – a 55-staff engineering consultancy in South Melbourne – was running their file server VM as a D16s_v5 because the original migration consultant ‘matched the on-prem CPU count.’ Seven days of metrics showed 4% average CPU. Rightsizing to a D2s_v5 saved $720 a month with zero user-visible impact.

2. Kill the orphaned disks

Every time someone deletes a VM through the portal, the OS disk and any data disks survive unless deletion was explicitly chosen. Over a few years, an SME tenant will accumulate 20 to 60 orphaned managed disks, often premium SSDs at $0.15 per GB-month. A 1 TB orphaned premium disk is $150 a month for storing absolutely nothing useful.

Run a quick KQL query in Azure Resource Graph to find disks where ManagedBy is empty. Validate that none of them are being held intentionally (some teams keep a disk for a few months as a ‘soft delete’ before truly removing it), then delete the rest. Easy win, usually $400 to $1,200 a month.

3. Reserved instances or savings plans for the steady-state workloads

Anything that runs 24/7 in steady state – production servers, domain controllers, a SQL VM, a file server – is paying full pay-as-you-go pricing by default. A one-year Reserved Instance is roughly 30% cheaper; three years is closer to 50%. The Azure Savings Plan for compute is more flexible (it covers any VM family in any region for the commitment amount) but a slightly lower discount.

The decision rule we use: if the workload is going to run for at least the next 12 months as-is, take the one-year reservation. If it might move, resize, or change family within that window, take the savings plan. Three-year commitments only for genuinely static workloads.

4. Auto-shutdown for dev and test

Dev and test VMs do not need to run on weeknights or weekends. A standard Azure Automation runbook or the built-in Azure DevTest Labs auto-shutdown can cut a non-production VM bill by 65 to 75%. The cost is two hours of configuration and a 30-second wake-up delay when someone needs the box at 7am Monday. We have yet to meet a dev team that genuinely objected once the saving was shown.

5. Azure Hybrid Benefit

If you have Windows Server or SQL Server licences with active Software Assurance, the Azure Hybrid Benefit lets you bring those licences to Azure VMs and stop paying the per-hour Windows or SQL surcharge. The saving on a Windows Server VM is typically 40%; on a SQL VM it can be 60 to 75%. Almost every SME with Software Assurance is leaving this on the table because nobody enabled the toggle at deployment.

Check your existing fleet through Cost Management. Filter by ‘Windows’ or ‘SQL Server’ as a meter category. Anything not marked as Azure Hybrid Benefit is overpaying.

6. Archive cold storage

Storage account blobs default to the Hot tier. Anything older than 30 days that you have not touched should be in Cool ($0.0152 per GB-month versus $0.0184 for Hot) or, for compliance archives, the Archive tier ($0.00099 per GB-month). Lifecycle policies on the storage account do this automatically.

For a healthcare client of ours in Box Hill with a 14 TB compliance archive, moving the long-tail blobs from Hot to Archive saved about $230 a month. A small number per month but a clean, automated saving that compounds as the archive grows.

7. Kill unused public IPs

A standard static public IP is roughly $4.50 a month. Trivial individually, but most SMEs have 15 to 40 of them, half of which are unattached from their original VM or load balancer. Run an Azure Resource Graph query for public IPs with no associated resource, validate, delete.

8. Review egress

Outbound data transfer (egress) from Azure to the internet is roughly $0.087 per GB after the first 100 GB free per month. Backup tools that pull data out of Azure, a misconfigured replication target that goes through public endpoints rather than peering, a video conferencing recording archive that streams out to a local NAS – all of these can quietly produce $400 to $1,500 a month in egress charges that nobody knows about.

The fix is usually a routing change (route the traffic through a private endpoint or service endpoint) or a topology change (move the target into Azure rather than pulling the data out). The win is identifying the source first; Cost Management broken down by Meter Subcategory shows you where the egress lives.

The governance guardrails that actually stick

Quick wins are easy. Stopping the spend from creeping back up over the next 12 months is the hard part. The lightweight controls we recommend for SMEs – the parts of the textbook that work at this scale:

Subscription-level budgets and alerts

One budget per subscription, set to the monthly run rate plus 15%, with alerts at 80%, 100%, and 120%. The alerts should go to a real person (the CFO and the IT lead), not a shared mailbox. The 80% alert is the one that catches the problem before it becomes a quarterly variance discussion.

Do not bother with budgets at the resource group level for an SME; the maintenance overhead is not worth the precision. The subscription is the right granularity.

Tagging that the team will actually do

Enterprise FinOps documents will tell you to enforce 14 mandatory tags. The team will rebel. For SME purposes, three tags are enough: Environment (Prod / Dev / Test), CostCentre (or Department), and Owner (a person, not a generic mailbox). Enforce them with Azure Policy at subscription creation time so any new resource without the three tags is blocked.

Three tags get used. Fourteen tags get ignored, and then nothing gets used.

Quarterly cost review

One hour every three months. The IT lead and the CFO sit down with Cost Management, look at the trend, look at the top ten cost drivers, look at the variance against budget, and decide whether to act. That is the entire process. The output is a one-page note for the leadership team and a list of remediation actions for the next quarter.

This is the rhythm we run with our managed clients. It is also the rhythm where most of the savings actually surface, because it forces someone to look at the data on a cadence that catches problems while they are small.

The three traps

Three patterns catch almost every SME on Azure. Worth understanding them before they catch you.

Trap 1: Lift-and-shift over-provisioning

The most expensive single mistake we see. A business migrates 12 servers from VMware to Azure and tells the migration partner to ‘match the existing VM sizes.’ The existing on-premises VMs were sized for peak load that occurs maybe twice a year, on hardware that was bought five years ago. The Azure VMs run hot for two hours a quarter and idle the other 99% of the time, but are billed at peak capacity every hour. Add up across 12 VMs and you are paying three times what the workload needs.

The fix is to size for Azure metrics, not on-prem habits. Migrate first, then watch the metrics for two to four weeks, then rightsize aggressively. We have done this exercise often enough now that we build the rightsizing step into the migration plan from the start. If the migration partner does not include a post-migration optimisation phase, that is a warning sign.

Trap 2: The dev environment that became production

A developer or contractor spins up a dev environment to test a workload. The business comes to rely on it. Three years later it is processing real production data on a ‘temporary’ subscription with no monitoring, no backup, no DR, and no reserved instances. It is also costing twice what it should because no one ever optimised it.

The fix is governance at the subscription creation step. No new subscription without a documented owner and an explicit lifecycle (this is a permanent prod subscription, or this is a 90-day project subscription with an automatic shutdown date). Cleaning up after the fact is harder than preventing it.

Trap 3: Defender for Cloud tier sprawl

Defender for Cloud is genuinely good, and the Standard tier offerings (Defender for Servers, Defender for SQL, Defender for Storage, Defender for Containers, Defender for App Service, and so on) protect real attack surfaces. The trap is that they bill per resource and the tiers are enabled per subscription. Click the wrong toggle and you have Defender for Servers Plan 2 running on every VM across every subscription for $24 each per month.

We have seen SMEs paying $4,000 a month for Defender coverage when their actual security need would be served by $800 of targeted enablement. The fix is to choose the plans deliberately, enable per subscription, and review quarterly. Defender for Servers Plan 2 on the workloads that need it; off everywhere else. Defender for Storage on accounts with sensitive data; off on the public assets bucket. The protections matter; the indiscriminate enablement does not.

For the security-side conversation about what to leave on, our Melbourne cyber security services page outlines the decisions we apply on the managed side. Cost and security are the same conversation in Azure; you cannot optimise one without involving the other.

What the FinOps tooling landscape looks like for SMEs

The third-party FinOps tools (CloudHealth, Cloudability, Apptio Cloudability, Flexera) are excellent but enterprise-priced. For an SME at $50k to $500k annual Azure spend, the native Azure tooling is enough:

If your spend grows past $1 million a year, the third-party tools become defensible. Below that, the native tooling is fine and the discipline matters more than the platform.

A small-business worked example

A 65-staff manufacturing business in Bayswater came to us in late 2025 with an Azure bill of $14,800 per month and a CFO who could not get a straight answer about why. Two weeks of focused work:

• Rightsized seven over-provisioned VMs, saving $2,100 per month
• Deleted 23 orphaned premium disks, saving $1,400 per month
• Applied Azure Hybrid Benefit to 12 Windows VMs (they had Software Assurance through their CSP and no one had enabled the toggle), saving $1,800 per month
• Switched the steady-state production workloads to one-year savings plans, saving $1,200 per month
• Set up auto-shutdown on the dev and test environments, saving $600 per month
• Identified and re-routed an egress problem through a private endpoint, saving $400 per month
• Trimmed Defender for Cloud tier coverage to the workloads that actually needed Plan 2, saving $700 per month

Total monthly saving: $8,200, or about 55% of the original bill. The new run rate of $6,600 per month is a defensible number for the workload, with no production impact and no reduction in security posture (in fact a more deliberate one). Subscription budgets, three-tag enforcement, and quarterly review cadence are now in place. The job took us about 70 hours across two engineers from our 13-strong Melbourne team and was delivered alongside the regular per-user fixed monthly managed IT engagement.

FinOps and the broader cloud strategy

Cost optimisation is one strand of a wider conversation about whether the cloud architecture is right for the business. Sometimes the answer to a high bill is to optimise; sometimes it is to redesign. A 24/7 SQL workload that processes a fixed batch overnight may be better suited to Azure SQL serverless or even a scheduled VM. A file server that nobody touches for three months at a time might belong in Azure Files cool tier with a small AVD presence on demand. These are not quick wins; they are architecture changes. But once the quick wins are taken, the conversation moves to design.

For Melbourne SMEs that want a second opinion on whether the architecture is right before committing to another year of the existing spend, we run cloud architecture reviews as a discrete piece of work, separate from ongoing managed services. They are useful at the 12-month mark of any non-trivial Azure deployment. Reach us through the contact page if that is the conversation you need.

Frequently Asked Questions

Should we move away from Azure to save money?

Almost never the right answer for a workload that is already in Azure. Egress fees on a full re-platform are punishing, the operational disruption is real, and the cost difference between Azure, AWS and GCP for SME-typical workloads is usually under 15% once both are properly optimised. Optimise what you have before considering a move. The exception is a workload that genuinely fits a different platform’s primitives better (a heavy GCP BigQuery analytics workload, for example).

How often should we revisit our reserved instance commitments?

At the renewal point and at any major workload change. The Azure Savings Plan is more flexible than the older Reserved Instances because it does not lock you to a VM family; if your workloads shift, the savings plan keeps applying. We typically recommend a mix: reservations for the most stable workloads (domain controllers, file servers, the SQL VM that has run unchanged for three years), savings plans for the rest.

What does FinOps mean for our cloud backup and DR spend?

Backup storage tends to live outside the day-to-day cost conversation and grows quietly. Same principles apply: tier the storage (most backup data can live in cool or archive after 30 days), review retention against actual recovery needs, and watch the egress when you do a restore. Our companion piece on backup and disaster recovery for Melbourne businesses goes deeper on the design decisions.

Do we need a dedicated FinOps person?

Not at SME scale. The work is two to four hours a month for an experienced engineer plus a quarterly review with the CFO. We run it as part of the managed engagement for clients on our per-user fixed monthly pricing model. Hiring a dedicated FinOps person is a sensible move at around $2 to $3 million annual cloud spend, not before.

Will the optimisation work introduce risk to production?

It can if it is done carelessly. The discipline is: validate against metrics before any resize, take a backup before any storage change, do the work in a maintenance window, and have a rollback path. We have done hundreds of these exercises with our MSP Melbourne clients without a production incident, but the process matters. A weekend cowboy resize of a production SQL VM is how you cause an incident.

What is the role of the CFO in cloud cost management?

The CFO owns the budget and the variance conversation; the IT lead and the MSP own the technical optimisation. The quarterly review is the meeting where those two functions talk to each other. Most SME cost creep we see comes from a lack of that conversation rather than from any technical failure.

Network segmentation gets explained as a zero-trust enterprise project with microsegmentation and identity-aware proxies. That framing scares SMEs off, which is a shame. A 30-person Melbourne business can segment its network usefully in a weekend with a UniFi stack and four VLANs. The hard part is sequencing the work so each step reduces real risk.

This guide is the practical version. We will walk through the minimum-viable segmentation that actually reduces lateral movement risk for an Australian SME, the priority order (guest Wi-Fi first, because it is the cheapest win and stops half the dumb risks), where SMEs over-engineer and waste budget, a sample VLAN and firewall rule pack you can adapt, and the trap of segmenting your network without doing the identity work alongside it.

TechAssist has been deploying these stacks for Melbourne SMEs since we were founded in 2014. Our cybersecurity services Melbourne team treats segmentation as one of the highest-leverage controls available to a small business. It is not the most exciting work, but it is the work that means a phished receptionist credential does not become a domain-wide ransomware incident.

What Network Segmentation Actually Is

Segmentation is the practice of dividing your network into separate zones so that a device or user in one zone cannot freely communicate with devices in another zone. Each zone is governed by firewall rules that say what traffic is permitted between it and other zones.

The simplest example: your guest Wi-Fi should not be able to talk to your office laptops. Your office laptops should not be able to talk to your CCTV cameras. Your CCTV cameras should not be able to talk to your phone system. Your phone system should not be able to talk to anything except the SIP provider. If you implement those four rules, you have already done most of the segmentation work that meaningfully reduces risk.

The reason segmentation matters is lateral movement. Modern ransomware does not just encrypt the machine it lands on. It enumerates the local network, finds open shares, weak credentials, and unpatched services on other devices, and spreads. A flat network gives the attacker the entire estate. A segmented network gives them one VLAN.

This is not zero trust, despite what some vendors will tell you. It is the perimeter approach with internal perimeters added. Zero trust is the next step beyond segmentation, where every connection is authenticated and authorised regardless of zone. Read our zero trust security model explained guide for that broader picture. For most SMEs, getting segmentation right is the prerequisite, and the right place to stop for now.

The Minimum Four VLANs for a Melbourne SME

If you run a 15-to-100-person business and you want a segmentation design that actually reduces risk without becoming a multi-month project, run four VLANs. We deploy this exact pattern several times a quarter across our client base.

Four VLANs sound trivial. The reason it is enough for most SMEs is that each one represents a meaningfully different risk profile. Guest devices are unmanaged and untrusted. IoT devices are notoriously badly patched and run weird firmware. Voice devices have their own QoS needs and should not be exposed to general office traffic. Corporate is the only zone where managed, patched, and authenticated devices live.

If you have a meaningfully different workload, like a manufacturing floor with PLCs, an OT environment, or a clinical environment with medical devices, add a fifth VLAN for that. Do not collapse it into the IoT VLAN. The blast radius if it gets compromised is too different.

Priority Order: Guest WiFi First

The single highest-leverage step you can take is splitting guest Wi-Fi from corporate Wi-Fi. It is cheap, it is fast, and it removes the most common dumb risk: a visitor’s compromised phone or a contractor’s malware-laden laptop pivoting onto your file server because they got the office Wi-Fi password.

The order we deploy in for a typical Melbourne SME segmentation engagement is as follows.

Week one. Guest Wi-Fi on its own VLAN with a captive portal, time-limited credentials, and a firewall rule that permits internet egress only. No access to internal subnets. This alone removes about 40 percent of the lateral movement risk for a typical SME.

Week two. Voice VLAN. Move the SIP phones onto their own VLAN, lock egress to your SIP provider’s IP range only, and prioritise QoS. This stops a compromised phone from talking to anything except the SIP provider and improves call quality at the same time.

Week three. IoT and AV VLAN. Move printers, cameras, smart TVs, AV gear, and any other unmanaged device onto its own VLAN. Permit only the management traffic the corporate VLAN needs (Bonjour and mDNS reflection for AirPrint, print server traffic, RTSP for camera viewing). Block everything else.

Week four. Corporate VLAN cleanup. Remove anything that should not be on the corporate VLAN, audit static IPs, document the segmentation in a network diagram, and set up monitoring alerts for inter-VLAN traffic that violates the rule set.

That is a four-week project for a typical 30-person Melbourne SME. Most of the cost is engineering time, not hardware. If you are already on UniFi, the hardware is essentially free, and the labour is roughly fifteen to twenty engineer-hours including documentation.

Where SMEs Over-Engineer

Segmentation has a way of attracting over-engineering. Here is what to skip if you are a 30-to-100-person business.

Microsegmentation. This is the practice of giving each workload or application its own segment with policies down to the application port level. It is the right answer for large enterprises with data centres and dozens of regulated workloads. It is not the right answer for a 40-person Melbourne law firm with one practice management system. Microsegmentation tooling costs more than the entire SME’s segmentation budget and adds operational complexity that the IT team cannot maintain.

Per-application firewalls. The pattern where each application has its own next-generation firewall with deep packet inspection rules. Same logic as above. It belongs to the enterprise data centre, not the SME network. For SMEs, a single perimeter firewall with sensible inter-VLAN rules covers the same risk at a fraction of the cost.

Identity-aware proxies for every internal application. Good idea in theory. In practice, deploying ZTNA across every internal app for a 30-person business takes three to six months of integration work, costs tens of thousands in licensing, and leaves the team frustrated. Start with corporate, guest, IoT, and voice segmentation. Then layer identity-aware access onto the two or three highest-value internal applications. Do not try to do all of it at once.

Dedicated SIEM and SOAR. SMEs that try to deploy a SIEM and incident orchestration platform alongside segmentation usually end up with both half-deployed. Use Microsoft Defender for Business or your MSP’s monitoring stack until you genuinely outgrow it. Our managed IT services Melbourne programme includes 24/7 NOC monitoring out of our Tecoma office, which covers what a small SIEM does for a fraction of the cost.

Sample VLAN and Firewall Rule Pack

Here is a sample rule pack that we deploy as a starting point on UniFi, pfSense, or Meraki gear. Adapt the IP ranges to your environment. The rules are written as “from-to: permit/deny.”

The thing to notice about this rule pack is how restrictive it is by default. Most SMEs run flat networks where everything can talk to everything. That is the disease. The cure is “deny by default” between VLANs and explicit permits only for the traffic you actually need. If you do not know whether a traffic flow is needed, it is not needed. Add it back if something breaks.

One detail that catches people out: print discovery. Modern printers use mDNS and Bonjour for discovery, which is broadcast-based and does not cross VLAN boundaries by default. You need either an mDNS reflector (UniFi calls it mDNS, Meraki calls it Bonjour Forwarding) configured between corporate and IoT VLANs, or you fix the printers in DNS with static A records and add them as IP-based printers. Both work. We usually prefer the static DNS approach because it is more deterministic.

The Trap: Segmenting Without Identity

This is the trap that costs SMEs more than any other in segmentation projects. You spend a weekend deploying four VLANs, you write a clean rule pack, you feel great, and then a phished user credential turns out to be a domain admin because identity hygiene was never done. The attacker authenticates as a privileged user, traverses your VLAN rules using legitimate credentials, and segmentation buys you nothing.

Segmentation is necessary but not sufficient. You also need identity hygiene. The minimum identity work to do alongside segmentation is as follows.

One. No standing domain admin. Domain admin rights are granted just-in-time, ideally through Privileged Identity Management in Entra ID, or at minimum through a separate dedicated admin account that requires MFA and is not used for email or browsing.

Two. MFA on everything. Not just email. RDP gateways, VPN, the firewall admin interface, the switch management interface, the wireless controller, the file server admin. If a credential gives access to something, that access requires MFA.

Three. Conditional access policies on Entra ID. At a minimum, require MFA for all users, block legacy authentication protocols, and require a compliant device for access to admin roles and high-value applications. This is included in Microsoft 365 Business Premium and is one of the highest-leverage controls available.

Four. Local admin password randomisation. Every Windows endpoint should have a unique, randomised local administrator password managed via LAPS or its modern equivalent in Intune. A consistent local admin password is one of the fastest paths to lateral movement, and most SMEs still have it.

Five. Application control allowlisting on at least the corporate VLAN endpoints. This is the hardest of the Essential Eight to deploy well, but it is also one of the most effective. See our deep dive on application control for the practical playbook.

Without those identity controls, segmentation is theatre. With them, segmentation becomes a meaningful second line of defence.

A Melbourne Example: 38-Person Architecture Practice in Richmond

A 38-person architecture practice in Richmond engaged us in early 2025 after a near-miss incident. A user clicked a phishing link, entered credentials into a fake Microsoft login page, and an attacker logged into their mailbox. The mailbox had access to a shared SharePoint library with five years of client documents, and the attacker started downloading files before MFA challenges (delayed by a policy gap) interrupted them.

The post-incident review showed three problems. First, no conditional access policy requiring MFA on every sign-in. Second, no device compliance check, so the attacker authenticated from an unmanaged device with no resistance. Third, flat network with no segmentation, so if the attacker had pivoted from email to internal systems, nothing would have stopped them.

We deployed in three phases. Phase one was identity hardening: conditional access, device compliance, MFA enforcement, LAPS on the Windows fleet. Phase two was segmentation, exactly the four-VLAN pattern above, with the addition of a fifth VLAN for the Revit project file server because it is high-value and warrants its own zone. Phase three was monitoring: alerting on inter-VLAN traffic that violated rules, alerts on impossible-travel sign-ins, and alerts on download volume anomalies in SharePoint.

Total project cost: just under $34,000 across three months. Total engineer time: 58 hours. Hardware: $4,800 of UniFi gear that replaced a single flat-network router and a consumer-grade access point. They have had zero security incidents in the eighteen months since.

The most important detail: the segmentation work would have been worthless without the identity work that came first. We do not deploy VLANs as a standalone project anymore. Segmentation comes packaged with identity hardening, or it does not come at all.

Hardware Choices: UniFi, Meraki Go, or Meraki Proper

Three tiers cover almost all Melbourne SME deployments. Each has trade-offs.

UniFi from Ubiquiti is the SME favourite for good reason. Hardware is one-time-cost, no recurring licences, the controller is good, and the gear is genuinely capable of handling four-to-six VLANs and the rule pack above. The trade-off is that you (or your MSP) own the operational lift. If the controller falls over, no vendor support phone number rescues you. We deploy UniFi for clients with an MSP relationship in place, because the MSP carries the operational responsibility.

Meraki Go is the entry-level cloud-managed option from Cisco. It is easy to set up, has a clean phone app, and is a good fit for businesses under 20 staff who want minimal operational complexity. The trade-off is feature ceiling. Once you want VLAN-aware DHCP scopes, more than basic firewall rules, or advanced visibility, you hit the ceiling. We tend to deploy Meraki Go for businesses we do not co-manage.

Meraki proper (the full Cisco Meraki dashboard) is the right answer for SMEs with serious compliance ambitions or with multi-site setups. The licensing cost is real (typically $80-$200 per device per year), but the cloud management, deep visibility, and reliability are excellent. We deploy this for clients in regulated sectors and for clients with three or more sites where central management saves enough engineer time to pay for itself.

None of these is the wrong answer. The right answer depends on whether you have an MSP, your compliance trajectory, and how much operational lift you want to carry yourself. Our MSP Melbourne team scopes the hardware decision as part of the segmentation engagement so the gear matches the operating model.

Monitoring: How You Know Segmentation Is Working

Deploying segmentation and not monitoring it is half the job. You need to know when a rule is being violated, when a device is in the wrong VLAN, and when traffic patterns indicate something abnormal.

The minimum monitoring set for an SME deployment:

Alert on denied inter-VLAN traffic above a threshold. A few denied packets are normal background noise. A sustained pattern of denied traffic from one IoT device trying to talk to a corporate file share is a signal worth investigating.

Alert on new devices in any VLAN. Especially the corporate VLAN. If an unknown MAC address suddenly appears, you want to know.

Alert on devices moving between VLANs. This should almost never happen during normal operations. If a device hops from IoT to corporate, something is misconfigured or, worse, someone is poking at the network.

Alert on rule changes. The firewall rule pack is now a security control. Changes to it should be logged, ideally reviewed, and definitely not made silently.

Our 24/7 NOC out of Tecoma handles this monitoring for our managed clients. We respond to P1 incidents in under 15 minutes and are on-site across Melbourne metro within the same business day when something needs hands on gear. For clients running their own ops with our co-managed IT support model, we share the monitoring with the internal team and escalate when thresholds are crossed.

How This Fits With Essential Eight and ISO 27001

Segmentation is not explicitly an Essential Eight strategy, but it is referenced under several of them and is foundational to a Maturity Level Two posture. Restricting administrative privileges, restricting Microsoft Office macros, and application control all become more enforceable when segmentation has limited the blast radius of any single compromised endpoint.

For ISO 27001, segmentation falls under Annex A.13 (Communications Security) and contributes evidence for several other controls. We do not certify clients (we are ISO 27001 capable, not a certifying body), but we have helped a number of Melbourne SMEs pass certification audits, and segmentation always shows up positively in the auditor’s review.

For Privacy Act obligations, segmentation reduces the population of data potentially affected in a breach, which can change the calculus on notifiable data breach decisions. See our Privacy Act for SMBs guide for the data handling context.

What This Costs for a Typical Melbourne SME

The all-in cost for a 30-to-50-person SME segmentation engagement, including identity hardening and ongoing monitoring, breaks down roughly as follows.

Total project cost typically lands between 20 and 30 thousand dollars depending on existing hardware, site complexity, and how much identity work is needed alongside the segmentation. The ongoing monitoring sits inside our per-user fixed monthly managed service pricing, so there is no surprise on the operational side.

Compared to the cost of a single ransomware incident (we covered this in another article and the realistic number for an SME is between $150,000 and $400,000 including downtime and customer churn), the segmentation project pays for itself if it prevents one incident. The maths is usually obvious in the boardroom.

Frequently Asked Questions

Can I do segmentation myself with a consumer router?

No. Consumer routers do not support meaningful VLAN tagging, and the firewall capabilities are not granular enough to write the kind of rule pack that makes segmentation worth doing. You need at minimum a small-business gateway like a UniFi Cloud Gateway, a Meraki Go GX, or an equivalent. The hardware costs less than a couple of staff laptops, so the price is not the obstacle.

Will segmentation slow down my network?

On modern gear, no. The gateway processes inter-VLAN routing at line rate, and the firewall rules add microseconds of latency, not milliseconds. The only place we see performance issues is when an SME tries to deploy deep packet inspection and TLS interception on undersized hardware. If you size the gateway correctly for your throughput, segmentation is invisible to users.

Do I need separate physical switches for each VLAN?

No. VLANs are logical, not physical. One managed switch handles all four VLANs at once, tagging traffic on the uplink to the gateway. The only reason to use physically separate switches is for an OT or industrial environment with very strict isolation requirements, and that is not most SMEs.

What about working from home: do segmentation rules apply on the VPN?

This is the part that gets missed. If your remote workers VPN in and land in the corporate VLAN by default, your segmentation has a hole. The fix is either a separate VPN VLAN with its own rule set, or, better, moving away from VPN entirely and using Entra ID conditional access with device compliance checks for application access. The latter is the modern approach and avoids the VPN-as-trust-domain problem entirely.

How often should the rule pack be reviewed?

Quarterly at minimum, and after any significant change to the application stack. We review rule packs as part of our managed client quarterly business reviews, and we use those reviews to remove rules that are no longer needed (which is more common than adding new ones).

What if a vendor needs access to one of my internal systems?

Vendor access should land in a dedicated vendor-access zone with explicit rules to the specific systems they need. Do not give vendors guest Wi-Fi credentials and ask them to VPN. Do not give them corporate Wi-Fi access. A dedicated zone with explicit permissions, ideally with MFA and time-bound credentials, is the right pattern.

How do I get started?

The honest first step is an assessment. We will look at your existing network, your endpoint fleet, your identity setup, and your compliance trajectory, and we will give you a sequenced plan. We do this for Melbourne clients regularly out of both our Tecoma office and our 575 Bourke St CBD office. Reach the team via the contact page and we will sort out a discovery session.

Most SME IT is unconsciously designed for the median 35 to 45-year-old user. That median user does not exist alone in the modern workplace, where four generations work alongside each other with very different expectations of technology. This is a Sunday read about designing IT that serves all your staff, not just the comfortable middle.

The four-generation reality

Walk into a typical Melbourne SME today and you will find a 22-year-old graduate, a 38-year-old manager, a 52-year-old senior operator, and a 64-year-old founder or long-tenured staff member all working in the same office. They use the same Microsoft 365 tenant, the same Wi-Fi, and the same helpdesk. They have completely different mental models of how technology is supposed to work, and most SME IT environments accidentally privilege one of those mental models over the others.

Since founding TechAssist in 2014, we have onboarded hundreds of SMEs and watched the generational mix shift through every one of them. The pattern in 2026 looks like this:

For a 60-staff Brunswick design agency we manage, the split is roughly 28% Gen Z, 52% Millennial, 16% Gen X, and 4% Boomer (the founder and one long-tenured operations director). For a 90-staff manufacturing business in Bayswater, the same split is 8% Gen Z, 31% Millennial, 44% Gen X, and 17% Boomer. Same Microsoft 365 tenant, completely different IT delivery requirements.

What each generation actually expects

These are generalisations, and individuals vary wildly within every group. They are still useful generalisations because the average matters when you are designing a helpdesk channel mix or a default permission set.

Gen Z

Gen Z grew up with iPads, Discord, TikTok, and friction-free consumer tech. Their reference point for ‘good software’ is whatever app they used last on their phone. Their expectations:

• Chat-first communication; phone calls feel intrusive
• Self-service everything; if there is a form, they will not fill it in
• Search-driven discovery rather than menu navigation
• Zero tolerance for slow interfaces or multi-step authentication friction
• Limited muscle memory for keyboard shortcuts or file system organisation
• Strong assumption that anything they need will be Googleable or YouTube-able

What this means in practice: Gen Z staff bounce off old-fashioned ticket portals, do not read documentation, and will quietly use a personal Notion or a personal ChatGPT account rather than ask IT for help. The risk is shadow IT and data leakage, not refusal to use tools.

Millennial

The bulk of most SME workforces. Grew up with the internet as it commercialised, formed their work habits with email and Slack, and have generally adapted to whatever tech their workplace put in front of them. Their expectations:

• Self-serve when possible, but happy to raise a ticket when needed
• Comfortable with both chat and email; tolerant of phone if the situation calls for it
• Strong adoption of new tools when the value is clear
• Reasonable security hygiene if it has been trained
• Power users of collaboration tools (Teams, SharePoint, project management)

Most SME IT is implicitly designed for this group. They are easy. They are also the group most likely to get over-prioritised because they make up the largest share of the helpdesk inbound.

Gen X

Gen X formed their work habits in the late 1990s and early 2000s, in the transition from paper to digital. They are often the most productive group with established workflows, and they are often the silent shadow IT contributors because they have been carrying habits from old systems forward for two decades. Their expectations:

• Get the job done; do not care about new shiny tools unless they obviously help
• Email-first, with chat as a tolerated overlay
• Strong file system mental model; may struggle with SharePoint’s metadata-first approach
• Quietly use personal Dropbox, Evernote, or other tools they brought with them from a previous job
• Will phone the helpdesk if email is taking too long

The shadow IT pattern in this generation is the biggest hidden risk in most SMEs. It is rarely malicious. It is almost always ‘I have been doing it this way since 2008 and nobody told me to stop’.

Boomer

Often the founder, often a director, often the most experienced person in the room with the strongest informal authority. Their expectations:

• Phone or in-person support, preferably from someone they know by name
• Email as the dominant communication channel
• Reluctance to adopt new tools without strong evidence of value
• Trust-based rather than process-based interaction with IT
• Will phone the helpdesk for a captcha that has stumped them, and will be frustrated if the helpdesk does not pick up immediately

The Boomer cohort is often the smallest by headcount and the largest by IT influence per person. A board member who cannot get into Teams before a meeting will create more helpdesk pressure in five minutes than 20 Millennials in a week.

Helpdesk channel design for a four-generation workplace

The default modern helpdesk is a ticket portal plus a chat channel, optimised for self-service. This works for Gen Z (chat) and Millennials (either) but actively fails Gen X and Boomers, who often prefer phone or walk-up. The solution is not to abandon chat; it is to offer all four channels with deliberate routing.

Running all four channels properly is expensive if you do it yourself with a small internal team. It is one of the practical reasons SMEs move to an MSP arrangement. Our 13 Australian engineers cover all four channels from our 24/7 NOC in Tecoma and our 575 Bourke Street CBD office, with a contractual sub-15-minute P1 response and same-business-day on-site response across Melbourne metro. That coverage model is hard to replicate with internal staff under about 8 IT FTEs, which is well beyond most SMEs.

Training that does not condescend

The single fastest way to lose generational goodwill in IT training is to pitch every session at the lowest common denominator. A 24-year-old Gen Z staff member sitting through ‘how to attach a file to an email’ becomes a future shadow IT user because they have learned that IT is not where help comes from. A 64-year-old Boomer thrown into a fast-paced ‘we will assume you know Slack’ onboarding becomes a future helpdesk regular because they did not catch up.

Tiered training

The model that works in SMEs is tiered training with self-selection. Offer three tiers of every major training session: foundational (assumes no prior knowledge), standard (assumes baseline comfort with the tool category), and advanced (assumes daily use, focuses on power features). Let staff self-select.

Almost everyone correctly self-assesses. The exception is a small subset of Gen X and Boomer staff who under-select out of pride and then struggle. The fix is a gentle 1:1 follow-up two weeks later: “How is the new system going? Is there anything you would like a walkthrough on?”

Avoid the metaphor trap

Training that leans on ‘this is like an old filing cabinet’ or ‘this is like sending a letter’ lands badly with Gen Z, who have never used either. Training that uses TikTok metaphors lands badly with Boomers, who have never used TikTok. The safest training language is concrete and operational: “Click here, then here, this is what happens, this is how to undo it.” Skip the metaphors entirely.

Documentation that respects time

Documentation needs to exist in two forms: searchable short-form (Notion pages, SharePoint articles, KB entries) for Gen Z and Millennials, and printable PDF or single-page reference sheets for Gen X and Boomers who learn by reading offline. The same content, different formats. The cost of producing both is modest. The cost of having only one is a generation that does not engage with documentation.

Default-deny vs default-allow assumptions

Modern security thinking, and the zero trust security model in particular, is default-deny. Nothing works unless it has been explicitly allowed. This is the right approach from a security perspective. It is also the approach that generates the most generational friction.

Gen Z and Millennials, raised on consumer apps that just work, find default-deny baffling: “Why can I not just install this thing? It is free.” Gen X and Boomers, raised on workplaces where IT controlled everything, find default-deny familiar but resent the friction when they are trying to do their actual job.

The path through this is not to compromise on default-deny. It is to invest in the user experience around it.

• Make exception requests easy. A two-click ‘request this app’ button beats a five-field ticket form every time.
• Publish a list of pre-approved tools clearly visible to staff. Most exception requests are for tools that would have been approved if the staff member had known.
• Communicate decisions back. “Your request for Tool X was approved/denied because Y” closes the loop and trains future requests.
• Treat the catalogue of approved tools as living. Add to it monthly. Staff who see the catalogue growing will treat exception requests as legitimate, not as a fight.

This is the practical application layer of application control, which is the hardest Essential Eight strategy to implement well. It is also the area where generational expectations matter most, because Gen Z will go around the control if the friction is too high.

The ‘tech buddy’ pairing model

One of the highest-leverage interventions we have seen in SMEs is the formal tech buddy model. Every new starter is paired with a tenured staff member from a different generation as their day-to-day go-to for small tech questions. The tech buddy is not IT; they are someone who already knows how the business uses the tools.

Why it works

• Reduces helpdesk inbound for small questions (estimated 12-25% reduction in our deployments)
• Creates cross-generational relationships in a way that other onboarding rarely does
• Surfaces shadow IT habits early, before they become entrenched
• Distributes IT literacy across the workforce instead of concentrating it

How to set it up

Pair new Gen Z starters with a Millennial or Gen X buddy who can model how the business actually uses tools. Pair new Boomer or Gen X starters with a Millennial buddy who can explain the modern collaboration patterns. The asymmetry is deliberate. The cross-generational pairing is where the learning happens.

For a Richmond marketing agency we manage, the introduction of the tech buddy model coincided with a 19% reduction in ‘how do I do X’ helpdesk tickets in the following quarter. The remaining tickets were genuinely harder problems that needed an engineer rather than a peer.

Specific design choices that help

Authentication friction

MFA is non-negotiable for any modern SME. The friction of MFA falls most heavily on Boomers, who are most likely to forget to bring their phone, lose their authenticator, or be confused by a passwordless prompt. Mitigations:

• Use Microsoft Authenticator passwordless or Windows Hello for Business as the default, not SMS codes
• Set up FIDO2 security keys (Yubikey) for users who repeatedly struggle with mobile MFA
• Conditional access policies that reduce MFA prompts on managed devices within the trusted network
• A clear and well-staffed account recovery process for the inevitable ‘I have lost my phone’ moment

Communication channels

Do not collapse all internal communication to Slack or Teams chat. The over-collapse of channels privileges Gen Z and disadvantages everyone else. Keep email viable for substantive communication, keep Teams or Slack for quick coordination, and keep phone open for urgent or sensitive conversations. Generational comfort follows the channel.

Device choice

Gen Z and many Millennials prefer Apple hardware for personal use and increasingly for work. Gen X and Boomers are typically Windows-fluent and find macOS unfamiliar. Standardising on Windows for cost and management reasons is the right call for most SMEs (and aligns with our endpoint policy recommendations), but be explicit about it and explain why. Treating Mac requests as unreasonable rather than as a legitimate preference creates a generational rift.

The Boomer founder problem

Worth a section of its own because it is so common in Melbourne SMEs. The founder, often Boomer or older Gen X, has built the business over 20 to 40 years. They use technology pragmatically but have not personally driven a tech refresh in five years. They are often the bottleneck for any decision about new tools, and they often have the strongest informal control over IT spend.

Two failure modes:

1. The ‘just make it work like the old one’ instruction. Migrations and modernisations get blocked because the founder cannot accept that new tools will not exactly replicate the old ones. Solution: explicit acknowledgement that the new tool is different, paired with a clear demonstration of what gets better. Avoid ‘training’ the founder; offer to sit with them for an hour and walk through the actual workflows they use.
2. The ‘I do not need that’ veto. Security investments and modernisations get blocked because the founder personally does not feel the pain. Solution: frame the conversation in terms of business risk rather than personal benefit. The Privacy Act compliance work and the Essential Eight investments protect the business; they are not optional convenience features.

For a Mount Waverley accounting firm we work with, the founder (mid-60s) had been blocking a move from a self-hosted file server to OneDrive and SharePoint for three years. The breakthrough came not from another training session but from a one-hour walk-through where one of our senior engineers sat with him and showed him how his existing daily file workflow would work in the new environment. The migration completed within two months. The block had been about uncertainty, not opposition.

What this means for IT strategy

Designing IT for a multi-generational workplace is not about generational stereotyping. It is about acknowledging that the median user does not exist on their own and that a one-size-fits-all approach excludes more people than it includes. The practical implications:

• Run multiple support channels in parallel and route deliberately
• Invest in documentation in multiple formats
• Treat default-deny security as a UX problem to be solved, not a posture to be defended
• Pair new starters with cross-generational tech buddies
• Resist the temptation to over-collapse communication channels
• Make founder onboarding to new tools a personal walk-through, not a training session

This is the kind of operational design work that sits inside a properly run Melbourne MSP relationship. A good MSP brings the channel mix, the documentation discipline, and the engineering depth to make all of this work. A bad MSP gives you a ticket portal and expects everyone to use it.

If you want to talk through what this looks like for your specific generational mix and business model, get in touch. Every SME is a different blend, and the right IT delivery model depends on the actual blend you have.

Frequently Asked Questions

Are these generational patterns really that consistent?

On the average, yes. On the individual, no. We work with 64-year-old Gen X-borderline staff who out-skill 24-year-old Gen Z staff on technical fluency, and vice versa. The point is not to assume; the point is to design for the variance. If your IT delivery model only works for one generational profile, you are excluding the others.

Should we have generation-specific training tracks?

Skill-specific, yes. Generation-specific, no. Self-selecting tiered training is more dignified and more accurate than tracking people by age. Generation matters as a design input, not as a sorting category.

How do we handle Gen Z staff who refuse to use email?

You will lose this battle if you frame it as compliance. You will win it if you frame it as professional necessity. Most clients, vendors, and regulators still operate on email. Gen Z will use email for those interactions if you explain why and accept that internal communication can happen elsewhere. The compromise is appropriate.

Is the tech buddy model just unpaid IT support?

It is informal peer support, not unpaid IT support. The tech buddy answers small questions (where do I find the project template, how do I share this externally) that would otherwise become helpdesk tickets. They do not troubleshoot hardware failures or security incidents. Make the boundary clear and recognise the buddy’s time in their performance review.

How does multi-generational design intersect with security?

It intersects most heavily in the authentication and access control layers. The same MFA policy that is invisible to a Gen Z user creates daily friction for a Boomer who keeps misplacing their phone. The same default-deny posture that protects the business creates shadow IT pressure in Gen Z. Good security design accounts for both, not just one. This is why our cybersecurity practice spends as much time on user experience as on policy.

What is the single highest-leverage change we could make this quarter?

Introduce or strengthen the tech buddy model for new starters. It is cheap, it builds relationships, and it surfaces shadow IT patterns before they entrench. Most SMEs see meaningful reductions in helpdesk inbound within a quarter, and the cultural benefits outlast the operational ones.

The ‘just one more year’ laptop is the most expensive computer in your business. Once you account for warranty cost, ticket volume, productivity drag, and the security exposure of out-of-support hardware, the five-year-old machine in accounts is costing more than a new one would. Real numbers and a clean decision tree follow.

The honest TCO of a business laptop

Most SMEs assess endpoint refresh by looking at the purchase price. That is the wrong number. The right number is total cost of ownership across the working life of the device, which for a business laptop includes hardware acquisition, extended warranty, helpdesk tickets attributable to the device, productivity loss from slowness or failure, and the security risk premium of running unsupported software.

We have been tracking this data across our managed endpoint base since founding TechAssist in 2014, and the pattern is consistent. A Dell Latitude 5450 or Lenovo ThinkPad T14 purchased today at around $2,200 with a 3-year ProSupport or Premier warranty will deliver, on average:

• Year 1: 0.8 tickets per device, mostly setup and configuration issues
• Year 2: 1.4 tickets per device, mostly software and minor performance issues
• Year 3: 2.1 tickets per device, with the first hardware failures appearing
• Year 4: 3.6 tickets per device, often a battery or SSD swap, plus rising ‘this thing is slow’ complaints
• Year 5: 5.8 tickets per device, mostly performance complaints and software compatibility issues

At an average internal cost of $85 per ticket (including the user’s time, not just the helpdesk’s), a year-5 device is costing about $493 in support, plus the productivity hit from a user who is fighting their machine instead of doing their job. That productivity hit is the largest hidden cost, and it is what most SMEs miss when they decide to extend an endpoint refresh cycle.

Windows 11 changes the calculation

Until 2024, the SME endpoint refresh debate was mostly a productivity and support cost conversation. From October 2025, when Windows 10 reached end of support, the conversation became a hard security question. Microsoft will not issue free security patches for Windows 10 after that date. Extended Security Updates (ESU) for SMEs are available but priced to discourage them: USD $61 per device for year one, doubling each year for up to three years, on top of your existing licence costs.

The Windows 11 hardware requirement is the bigger issue. TPM 2.0, Secure Boot, and a compatible CPU are required. Most laptops sold before mid-2018 cannot run Windows 11 at all. Many laptops sold between 2018 and 2020 can technically run it but lag on performance. If you have devices in your fleet older than five years, the choice is no longer ‘replace or repair’, it is ‘replace, pay ESU, or accept the risk of unpatched endpoints’.

For Essential Eight alignment, running out-of-support operating systems fails the Patch Operating Systems control immediately. If you have any aspiration toward cybersecurity maturity or working with clients who require it, this is non-negotiable.

The replace-vs-repair decision tree

For every device in your fleet, the decision tree is:

1. Is the device Windows 11 compatible? If no, replace. The exceptions are devices that will be repurposed for a non-Windows use case (signage, kiosks, dedicated Linux workstations).
2. Is the device under warranty? If yes, repair through warranty for hardware failures. If no, move to step 3.
3. Is the device older than 4 years? If yes, replace rather than repair almost any hardware failure.
4. What is the failure? Battery and SSD swaps are usually repair-economic up to year 4. Motherboard, screen, or keyboard failures past warranty are almost always replace-economic.
5. Is the user a heavy use case? Developers, designers, video editors, and finance staff running large models tend to outgrow consumer-grade machines faster. For these users, lean toward earlier replacement.

The single most important question is the first one. Windows 11 compatibility is binary. There is no halfway. A device that cannot run Windows 11 is on borrowed time and every month of extension increases your security exposure.

The 3-year vs 4-year cycle debate

For years, the standard SME refresh cycle was 4 years, often stretched to 5. The recent move by most progressive MSPs has been toward 3 years, and the reasoning is worth understanding.

The case for a 3-year cycle

• Manufacturer warranties typically cover 3 years out of the box (extending to 4 or 5 adds noticeable cost)
• Tickets jump significantly from year 3 to year 4 (1.4 to 3.6 in our data)
• Resale value at 3 years is meaningfully higher than at 4, especially for ThinkPad and Latitude business lines
• Battery degradation past 36 months affects user productivity even when the device is technically working
• Operating system and software requirements creep upward; a 3-year-old device is current, a 5-year-old device is fighting Teams

The case for a 4-year cycle

• Higher capital cost per year averaged out, but lower total spend if devices truly are healthy at year 4
• Light-use users (front-of-house, occasional office users) often genuinely do not need a refresh at year 3
• Lease structures often align to 36 or 48 month terms; 48 spreads the cost more

Our recommendation

Run a 3-year cycle for heavy users and a 4-year cycle for light users, with the cohort defined explicitly during procurement, not retrospectively. Mixed cycles within a fleet are fine as long as the policy is documented and the lifecycle dates are tracked.

Lease vs buy in a high-AUD or volatile-AUD environment

The AUD has been volatile against the USD through 2025 and into 2026, and hardware pricing reflects it. Dell, Lenovo, and HP price in USD and adjust Australian list prices on a delayed basis. For an SME refreshing 30+ endpoints, the lease vs buy decision needs revisiting.

The instant asset writeoff has changed several times over the last few years and remains a moving target through the 2026 federal budget cycle. As at writing, the current rules support certain small business write-offs, but the thresholds and the eligible business turnover bands change frequently. Talk to your accountant before committing to an EOFY hardware purchase based on a write-off assumption.

For a Box Hill accounting firm we work with, 28 staff, the move from a buy-and-stretch model (5-year average device age) to a leased 3-year cycle through a major financier reduced their year-on-year IT support cost by 22% and removed the year-4 productivity drag entirely. The lease cost was higher in nominal monthly terms than the depreciation on the previous model, but the total cost was lower once support and productivity were included.

The ‘one device class, one image’ policy

One of the highest-leverage decisions an SME can make about endpoints has nothing to do with the refresh cycle. It is the decision to standardise on one device class with one operating system image.

What standardisation actually means

One business laptop SKU for everybody who needs a laptop (with a workstation-class SKU for the heavy users who genuinely need it). One desktop SKU for fixed-desk roles. One Windows 11 image, one set of pre-installed applications, one configuration baseline managed through Intune or your MDM of choice.

Why it matters

• Bulk pricing improves significantly when you buy 10 of one SKU instead of 2 each of five SKUs
• Spares and loaners are interchangeable, so a broken device can be swapped in 15 minutes
• Driver and firmware management becomes a single workflow instead of five
• Support tickets resolve faster because the helpdesk has seen this exact configuration a hundred times
• Security baselines are testable across the entire fleet

For a Port Melbourne logistics company we manage, the move from a mixed fleet (Dell, Lenovo, HP, a few MacBooks) to a single Lenovo ThinkPad SKU with one image reduced their endpoint ticket volume by 31% in the first year of the new policy. Not because the hardware was better, but because the standardisation killed an entire class of compatibility and driver problems.

Standardisation is also what enables sub-15-minute P1 response. When a director’s laptop dies on the way to a board meeting, our team can dispatch an identically configured loaner from our Tecoma or 575 Bourke Street CBD office, and a same-business-day on-site swap is achievable across Melbourne metro. None of that works if the fleet is heterogeneous.

The EOFY tax timing question

The Australian financial year boundary at 30 June makes endpoint refresh a tax-timing question every year. Should you bring forward purchases to claim depreciation or instant asset write-offs in the current FY? Should you defer to spread cost?

The current state of instant asset write-off

The instant asset write-off has been a moving target since the original $20,000 limit was raised, extended, contracted, and reset multiple times through COVID-era stimulus and subsequent budgets. As at the 2025-26 financial year, the threshold and eligibility rules sit at a different level than they did during the peak stimulus period. Do not rely on this post for current numbers; check with your accountant in the month you are planning to purchase.

The strategic question

Tax timing should be a tiebreaker, not a driver. If you genuinely need to refresh devices, the right time is when the devices need refreshing. Bringing forward a purchase by two months to capture a write-off can be smart. Deferring a needed refresh by six months to align with FY26 is almost never smart, because the support cost and productivity drag of the extra six months exceeds the tax benefit.

Bulk timing

For businesses on a 3-year cycle, batching refreshes once a year (typically May or June, into the new FY) is administratively cleaner than rolling refreshes throughout the year. Procurement is a single negotiation, deployment is a single project, and the depreciation schedule is clean. The downside is that a year-1 cohort all ages out together, but in practice the cohort approach also makes succession planning easier.

What to do with the old devices

Endpoint refresh is not finished until the old devices are properly disposed. Three options, with very different risk profiles.

Resale

Through a refurbisher or platform like Grays. Requires certified data destruction before transfer. Acceptable for devices in good condition with no sensitive role history. Capture the resale value against the new device cost.

Donation

To schools, charities, or community programs. Still requires certified data destruction. Generates goodwill and sometimes a tax deduction. The administrative overhead is non-trivial.

Certified destruction

For devices that held sensitive data, devices that failed, or devices with no resale value. Use a certified e-waste processor with a documented chain of custody. For businesses pursuing ISO 27001 capability or aligned to the Essential Eight, this is the only defensible disposal path for devices that handled regulated data.

For healthcare and legal practices in particular, the data on a returned laptop is the same data that triggered the Privacy Act compliance work. Treat disposal as a data security event, not an asset disposal event. Our healthcare IT practice and legal IT practice both build certified destruction into the refresh workflow as standard.

Putting it all together

A working endpoint refresh policy for a typical Melbourne SME looks like this:

• 3-year cycle for knowledge workers, 4-year cycle for light users, documented at procurement
• One device class (e.g. Lenovo ThinkPad T-series or Dell Latitude 5000-series) for all standard knowledge workers
• One workstation-class SKU (e.g. ThinkPad P-series or Latitude 7000-series) for heavy users
• Windows 11 Pro, one image, managed through Intune
• 3-year manufacturer warranty (ProSupport or Premier) bundled at purchase
• Annual batch refresh, typically May or June
• Lease structure for businesses with predictable growth or capex sensitivity
• Certified destruction or platform resale at end of life, with documented chain of custody

This is the kind of policy that lives inside a managed IT services arrangement with per-user fixed monthly pricing, because the MSP carries the refresh planning, the procurement leverage, and the deployment execution. For businesses that prefer to keep procurement in-house, the policy still works; you just need to run it yourselves.

Frequently Asked Questions

How do we handle devices for staff who travel constantly?

Heavy travellers are heavy users by definition; their devices take more wear, drop damage, and battery cycles. Move travellers to the 3-year cohort regardless of seniority, and consider upgrading to a workstation-class device with a longer battery and a heavier-duty chassis. The TCO maths almost always favours the more expensive device for users who live out of a bag.

What about Macs?

Macs have a different lifecycle pattern. Hardware tends to last longer (battery and SSD are the main issues), but macOS support tails off after about 7 years and Apple does not offer extended security updates the way Microsoft does. For Mac-using teams, a 4-year refresh cycle is realistic, and the resale value at 4 years is typically strong enough to materially offset the next purchase.

Are refurbished devices a viable option?

For light-use roles, yes. Certified refurbished business-class devices from a reputable refurbisher with warranty can be a sensible choice for 5% to 15% of a typical fleet, particularly for casual users or temporary staff. We do not recommend refurbs for knowledge workers, finance, or any role that lives on the device 8 hours a day.

What is the policy on bring-your-own-device?

BYOD has security and support cost implications that almost always exceed the savings. For staff who genuinely need it (contractors, casual freelancers, board members), use a managed app model on personal devices with Intune App Protection or similar. For employees, issue a managed device. The exception is mobile phones, where BYOD with corporate app containerisation is the more common pattern.

How does this fit with the rest of our IT strategy?

Endpoint refresh policy is one of the foundational decisions that sits underneath cybersecurity, productivity, and IT support cost. A coherent policy makes everything else easier. An incoherent policy or no policy makes everything else harder. If you are evaluating an MSP, ask them what their default endpoint policy looks like and how they enforce it. The answer tells you a lot about how they run their other operations.

Can we just keep extending the warranty?

Most major manufacturers will extend warranty by 1 or 2 years past the original 3-year term, but the cost ramps quickly and the warranty does not cover battery, productivity, or the security exposure of older hardware. For most SMEs, extending warranty past year 4 is more expensive than refreshing the device. If you want a deeper conversation about the right policy for your business, get in touch; this is the kind of question we work through with clients in onboarding.

If you cannot tell us in 30 seconds how many SaaS subscriptions your business pays for, you have SaaS sprawl. For a typical sub-$10M Australian SME, 5% to 12% of recurring SaaS spend is duplicated, unused, or forgotten. This post walks through a four-step audit you can finish before EOFY.

Why SaaS sprawl is a financial problem, not just an IT one

This is a deliberately financial post. We have a separate piece coming on Shadow IT, which covers the security angle. The audit process below is the one we run when a CFO calls us in May or June and says some version of: “I think we are paying for too much software and I do not really know what we have.” That conversation has happened more times this year than in the previous three combined, and EOFY is the moment to fix it because every subscription you cancel before 30 June reduces your run-rate cost for FY27.

SaaS sprawl is not a security incident, it is a slow leak. It happens because individual product subscriptions are small enough to fall under the discretionary spend threshold of most managers ($50 to $200 a month on a credit card), and big enough collectively to fund another two staff members. For a Hawthorn-based professional services firm we audited recently with 48 staff and around $7.5M revenue, the SaaS bill came to $186,000 a year. After audit, we cut it to $142,000 without removing any meaningful capability. That is one and a half graduate salaries, sitting in software nobody used.

Since founding TechAssist in 2014, we have run this exercise inside our managed IT engagements and as standalone projects. The methodology has stabilised into a four-step process that works for any SME with bookkeeping in Xero or MYOB and an executive willing to make some decisions.

Step 1: Extract the spend data

The first step sounds easy and is usually the hardest. You need a clean, single-source list of every recurring software charge the business has paid for in the last 12 months. Not what the IT register says you have. What the bank account and the credit card statements prove you have.

Pulling data from Xero

For Xero-based businesses, the export workflow is:

1. Go to Accounting, Reports, Account Transactions
2. Set the date range to the last 13 months (you want one full year plus the current month for renewal visibility)
3. Filter by the expense accounts you typically book software to: usually ‘Software Subscriptions’, ‘IT Expenses’, ‘Computer Software’, ‘Cloud Services’, and sometimes ‘Marketing’ for tools that snuck in via that team
4. Export as CSV

You also need the credit card transaction export, separately, because half the rogue subscriptions are on staff cards and never get coded to a software account. Pull the last 13 months of card statements and grep for any merchant name that looks like a SaaS vendor.

Pulling data from MYOB

For MYOB Business or AccountRight users, the workflow is similar: Reports, Accounts, Find Transactions, filter by account, export to Excel. The chart of accounts in MYOB tends to be messier than Xero in our experience, so you will want to also pull the All Journals report for the period and search the description column for known SaaS vendor names.

The Microsoft 365 admin centre and Google Workspace

Do not forget the platform you are already on. Microsoft 365 and Google Workspace both have a billing section showing all subscriptions, seat counts, and the per-seat price. Pull that as a separate dataset. You will use it later when you check seat utilisation against headcount.

At the end of step 1, you should have a single spreadsheet with columns for: vendor name, total annual spend, monthly spend (if recurring), billing frequency, payment method, charge account, and a blank column for ‘function’ which we fill in next.

Step 2: Deduplicate by function

This is where the audit gets interesting. Most SMEs do not think they have duplicate tools. Almost all of them do. The trick is to categorise every tool by the job it does, and then look for jobs being done twice.

Use a six-category matrix:

For each line in your spreadsheet from step 1, assign a category. Then sort by category and look for duplicates within each category. The patterns we find most often:

• Three project management tools, because each department picked their own and never standardised
• Two e-signature platforms (DocuSign for legal, Adobe Sign because it came in Acrobat Pro)
• Paid Zoom Pro alongside Teams Phone, when nobody actually needs Zoom anymore
• An old CRM still being paid for after the team migrated to a new one 18 months ago
• Multiple file-sharing tools (Dropbox, OneDrive, Google Drive, Box) because different teams brought in different ones
• Two password managers, one of which has six active users out of 40 seats paid

The team in our audit example that kept paying for Trello two years after moving to ClickUp is not an exaggeration. The Trello bill was $18 a user per month for 12 seats, $2,592 a year, billed to the credit card of a manager who left in 2024. Nobody had thought to cancel it because nobody had thought about it at all.

Step 3: Map each tool to a business owner

For every line in your now-deduplicated list, you need a named human who owns the decision to keep, kill, or consolidate. This is the step that breaks the audit at most SMEs, because nobody wants to own a tool nobody uses, and nobody wants to admit they signed up for the thing in the first place.

The ownership conversation

Run this as a structured exercise, not an email thread. Get the leadership team in a room with the spreadsheet on a screen. For each line, the question is: “Who is the business owner of this tool?” If nobody puts their hand up, that is the strongest possible signal that the tool should be killed.

Owners need two responsibilities clearly stated:

• They authorise the spend
• They are accountable for whether the business gets value from the tool

For tools that survive ownership assignment, you also want a documented use case (“we use Asana for client project tracking across the consulting team, 18 users”) and a renewal date.

Seat utilisation check

For every tool the business is keeping, pull the actual seat utilisation in the last 30 days. Most SaaS vendors have a ‘last active’ or ‘last login’ field in the admin console. Compare paid seats to actively used seats.

A South Melbourne creative agency we audited had 38 Adobe Creative Cloud licences for 24 people. The previous office manager had set up seats for every staff member because Adobe ran a promotion in 2022. Of the 38 seats, 19 had been used in the prior 90 days. Cutting back to 25 seats (24 plus one buffer) saved $11,800 a year. They had been paying $880 a month for unused creative software for 18 months.

Step 4: Kill, consolidate, keep

The final step is the decision. Every tool in your spreadsheet ends up in one of three buckets.

Kill

Tools with no owner, no use case, or zero seat utilisation. Cancel them before the next renewal. For tools billed monthly, the cancellation is easy. For tools on annual contracts, mark the renewal date in the calendar and set a reminder for 60 days prior.

Watch for cancellation friction. Some SaaS vendors require you to call a sales rep to cancel, especially on enterprise tiers. Budget time for this. Some require 30 or 60 days notice. Read the terms before you assume you can cancel today.

Consolidate

Two tools doing the same job, both with active users. The owner of each tool needs to pick one and migrate. Set a realistic migration timeline (usually 60 to 90 days for a project management tool migration; longer for a CRM) and a hard cancellation date for the loser.

Migration is the step where consolidation projects die. Account for the cost: someone needs to actually do the work, and the loser tool needs to stay paid until the migration completes. Build that into the savings calculation.

Keep

Tools with a clear owner, an active use case, and reasonable seat utilisation. For these, the audit work is rightsizing the seat count and aligning the billing frequency. Annual billing is usually 10% to 20% cheaper than monthly. If you are confident in the keep decision, switch to annual at renewal.

Typical wins for a sub-$10M SME

For Australian SMEs in the $2M to $10M revenue band, we consistently see SaaS audit savings of 5% to 12% of total SaaS spend. The mix typically breaks down like this:

For a Cremorne software business we worked with (32 staff, $4.8M revenue, $94,000 annual SaaS spend pre-audit), the savings broke down as $11,200 from killing unused tools, $9,800 from consolidating overlapping tools, $6,400 from rightsizing seats, and $2,100 from billing switches. Total $29,500 a year, 31% reduction. The audit itself took about 14 hours of staff time across three weeks.

The Excel template

The template we use internally has six tabs. You can build your own in an afternoon:

1. Raw data: CSV exports from Xero or MYOB, pasted as-is, one tab per source
2. Consolidated list: deduplicated by vendor, with annual spend, monthly spend, billing frequency, category, owner, use case, and decision (kill/consolidate/keep) columns
3. Seat utilisation: for each kept tool, the paid seats vs active seats vs target seats
4. Renewal calendar: all renewal dates in date order, colour-coded by criticality
5. Savings tracker: per-decision annualised saving, with a running total
6. Action log: what we cancelled, when, what we consolidated, and the realisation date for each saving

The most important tab is the action log. Audits are easy. Execution is hard. Without a tracked action log, half the decisions never get implemented and the savings never land.

Common mistakes during SaaS audits

Not including microservices and add-ons

Many tools are sold as the base product plus per-feature add-ons. HubSpot, Salesforce, Microsoft 365, Adobe Creative Cloud, all have premium add-ons that are often turned on by accident or for a one-off campaign and never turned off. Audit add-ons separately, not just the base product.

Ignoring the implicit licence inside another product

This is the biggest miss. If you are paying for Microsoft 365 Business Premium at $33 per user per month, you already have Teams (voice optional), SharePoint, OneDrive, Exchange, Intune, Defender for Office 365, Azure AD Premium P1, and Power Automate Free. If you are also paying for Slack, Dropbox, a separate identity provider, or a third-party MDM, you are paying twice. Map the included entitlements of your platform tier before assessing the standalone tools.

Forgetting personal credit card subscriptions

If staff expense SaaS through reimbursement, those subscriptions never hit the company card. They live in the expense system. Pull a year of expense claims and search for any vendor name that smells like software.

Treating it as a one-off

SaaS sprawl is a continuous problem. Without a recurring process, you will be back where you started in 18 months. Build a quarterly mini-audit into the finance calendar: every quarter, pull new SaaS charges, check ownership and use case, and add to the central register. This is the kind of governance that comes naturally inside a managed IT services arrangement with per-user fixed monthly pricing, because the MSP has a vested interest in keeping the SaaS register clean.

How this connects to your broader IT environment

A clean SaaS register is a precondition for several other things you probably need to do this year. It feeds directly into your cybersecurity posture, because every SaaS tool is an authentication surface and a data exfiltration risk. It feeds into your Privacy Act compliance, because the 2024 reforms require you to know where personal information lives, and ‘in some SaaS tool nobody can remember the name of’ is no longer acceptable. It also feeds your cloud services strategy, because a deduplicated tool stack is much easier to integrate and govern.

For Essential Eight alignment specifically, the audit is the foundation of the User Application Hardening control. You cannot harden applications you do not know exist.

When to bring in external help

You can run the audit yourself if you have a financially literate operations manager with a few spare hours each week and an executive willing to make decisions. If you do not, or if you suspect the audit will surface uncomfortable conversations about who signed up for what, an external party makes the process faster and less politically charged.

TechAssist runs SaaS audits as a standalone engagement or as part of broader managed IT onboarding. Our team of 13 Australian engineers includes the people who actually know which Microsoft 365 entitlements overlap with which standalone tools, which matters because most of the consolidation savings hide in that overlap. We run audits out of both our Tecoma office and our 575 Bourke Street CBD office, so we can do the workshop in person wherever your team is. If you want to start a conversation, the EOFY window is the right time.

Frequently Asked Questions

How long does a typical SaaS audit take?

For a 30 to 80-staff SME, plan on 12 to 20 hours of work spread over three weeks. The data extraction is the longest single task. The decisions can be made in two or three workshops if leadership is willing to commit time.

Can we just use a SaaS management platform like Vendr or Zylo?

Those tools are excellent for businesses with 200+ staff and SaaS bills over $500,000. For sub-$10M SMEs, the licence cost of the management tool is often higher than the savings it surfaces. Excel and a focused three-week project produce 90% of the result at 10% of the cost.

Should we cancel everything that has zero use, or migrate users first?

Confirm zero use across at least 90 days before cancelling, and notify the listed billing contact (not just the technical contact) before pulling the plug. Some tools are ‘used’ only at month-end or quarter-end and look dormant at other times. A 90-day window catches most of these.

What about free SaaS tools, do they matter for the audit?

From a cost perspective, no. From a security and governance perspective, very much yes. Free tools are where the data leaks happen. That conversation belongs in the Shadow IT review, not the financial audit.

Do we need to involve our MSP in the audit?

If you have one, yes. Your MSP often holds the admin credentials to half the tools you are auditing, knows the seat utilisation in real time, and can execute the cancellations on your behalf. If you run a co-managed IT arrangement, this is the kind of work that should already be part of your quarterly review with the MSP.

When is the right time of year to run the audit?

April or May, to bank the FY27 savings before 30 June. Cancellations made in May reduce your run-rate for FY27 and improve your EBITDA position before EOFY. Audits run in September or October are still valuable, but you have given up a year of savings.

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.

An internal IT team overwhelmed by demand looks like this: a growing ticket backlog, the same problem fixed for the third time this month, projects perpetually “next quarter”, and a senior tech who hasn’t taken a proper holiday since 2023. Work gets done — barely — but nothing improves.

If that sounds familiar, you’re not alone. We see it constantly across Melbourne — particularly in firms that grew from 30 staff to 120 over a few years without rebuilding the IT function to match. This article is for business owners, GMs and CFOs who already have an internal IT team of one to three people and are starting to notice the cracks. It’s a different problem from businesses with no formal IT support at all — those firms need a starting point. You need to fix something that’s already there.

Why this matters now

An overwhelmed internal IT team is one of the most expensive problems in a mid-sized business, and it’s almost always hidden. The salaries are already paid. The tickets are eventually closed. From the outside, IT looks “fine.” But underneath, three things are happening: security work is being skipped, your best technical person is quietly burning out, and the business is paying senior-engineer wages for help-desk work.

None of that shows up on a P&L line until something breaks. Then it shows up as a ransomware incident, a key resignation, or a $90,000 project that overruns by six months.

What “overwhelmed” actually looks like

Forget the abstract definitions. Here are the observable signs we walk into when a Melbourne business calls us about co-managing their IT.

1. The ticket backlog never shrinks

Healthy internal IT teams clear what comes in each week, with a slow-burn project queue running underneath. Overwhelmed teams have a backlog that grows steadily — 40 open tickets becomes 80, then 150. The team isn’t lazy. They’re triaging the loudest problem, fixing it, then moving to the next loudest. Nothing strategic gets touched.

A useful test: ask your IT manager how many tickets are older than 30 days. If they don’t know, or the number is above 10% of monthly volume, you have a capacity problem.

2. Projects have been “next quarter” for a year

Server replacement. Entra ID tenant cleanup. Backup verification. Migrating off that one legacy app nobody wants to touch. These projects sit on the roadmap because everyone agrees they’re important, but the team is too busy fixing today’s problems to start them. This is the clearest sign that the day-to-day load has consumed the team’s strategic capacity.

3. Security work is the first thing to get skipped

Patching schedules slip. MFA rollouts stall at 70%. Conditional access policies never get tightened past the defaults. The internal team knows it matters — they’re not negligent — but security work is usually invisible until it isn’t, so it loses every battle for time against a user who can’t print.

4. Everything breaks when Mark goes on holidays

Key person dependency is the dead giveaway. If your senior tech takes two weeks off and the team can’t function — passwords can’t be reset for certain systems, the firewall config is a mystery, nobody else knows how the backup actually works — you don’t have an IT team. You have one person and some helpers. This is fragile and it gets worse over time, because Mark stops documenting things he doesn’t have time to document.

5. Documentation is non-existent or three years stale

Ask to see the network diagram. Ask where the admin credentials are stored. Ask for the runbook on restoring email if the tenant goes down. If the answer is “it’s in Mark’s head” or “we had one but it’s old,” your team is past capacity. Documentation is the first thing that goes when people are flat out, and the absence of it makes everything slower.

6. After-hours work has become routine

Patching on Saturday nights. Answering Teams messages at 9pm. The senior engineer logging in from home on Sunday to fix the accounting export before Monday morning. Occasional after-hours work is part of the job. Routine after-hours work means the team is doing two jobs in one week and one of them is being done on personal time. It ends in resignation, usually with three weeks’ notice.

7. Your IT manager is doing tier-1 tickets

If the person you hired to run IT strategy is resetting passwords and unjamming printers, you’re paying $140k for $60k work, and the strategy isn’t happening. This usually means the team is short one or two technicians and the manager has been absorbing the gap.

8. Vendors are managing the team instead of the other way around

The internet provider, the phone system vendor, the line-of-business app support team — they’re all calling the shots about when things happen, because the internal team doesn’t have time to push back or coordinate. You start finding out about changes after they happen.

A concrete example

A professional services firm in South Yarra came to us last year. About 85 staff, two internal IT people — a manager and a junior. On paper, that’s a reasonable ratio. In practice, the manager was working until 7pm most nights, taking calls on weekends, and hadn’t started the Microsoft 365 security baseline project that had been approved 14 months earlier.

The junior was good but couldn’t operate without supervision on anything past tier-1. When the manager took annual leave over Christmas, the firm had three outages in two weeks because nobody else knew the environment.

The owner’s first instinct was to hire a third person. That would have helped, eventually — but the recruitment timeline alone was three to four months, and onboarding another six weeks before they were useful. Meanwhile the manager was 90 days from resigning. We don’t say that hypothetically; he told us so on the second meeting.

We ended up co-managing with them. Our team took over the after-hours load and the tier-1 ticket queue. Their manager kept ownership of strategy and the relationship with the business. Within six weeks the backlog was down 70%, the security project was running, and the manager was taking weekends off again. He’s still there.

Your three real options

When an internal IT team is overwhelmed, there are realistically three responses. The honest answer is that the right one depends on your situation — there’s no universal best.

When hiring is the right call

If your business is genuinely growing — adding 20+ staff per year, opening new sites, expanding the application stack — and you’ve got the management bandwidth to onboard and supervise, hiring is often correct. A third internal tech who knows the business deeply is worth a lot. Just be honest about the timeline. You’re not going to feel relief for six months.

When promoting works

Sometimes the team is fine but the structure is wrong. The senior tech is doing manager work informally, the junior is ready for more, and a quick reshuffle plus clearer responsibilities solves 60% of the problem. This works best in smaller teams where the issue is role ambiguity rather than headcount.

When co-managed makes sense

If your internal team is solid but drowning, co-managed IT is usually the fastest way to relief. The MSP takes over the predictable, repeatable work — tier-1 tickets, after-hours coverage, patching, monitoring — and your internal team gets back to the strategic work they were hired for. Done well, your manager keeps their job satisfaction and your business keeps the institutional knowledge.

This isn’t the same as fully outsourced managed IT, which replaces the internal team. Co-managed augments them. The distinction matters when you’re talking to staff about what’s changing.

What to look for in an MSP if you go co-managed

If you do head down the co-managed path, the wrong MSP will make your problem worse. They’ll squabble with your internal team over territory, fail to document what they do, and slowly position themselves to replace your internal staff. The right MSP behaves like a senior colleague to your IT manager, not a competitor.

• Australian-based engineers. Co-managed only works with tight collaboration, and that’s harder across time zones. TechAssist runs with 13 engineers, all Australian-employed.
• Real after-hours coverage. Not a voicemail and a callback. Our 24/7 Network Operations Centre at Tecoma in the Dandenongs handles overnight monitoring and incident response, which is exactly the load that’s killing your internal team.
• Fast response on critical issues. We target sub-15-minute response on critical tickets. If your internal team knows that backup is there, they sleep better.
• Clear scope. You should be able to draw a line between what the internal team owns and what the MSP owns, and update it as things evolve.
• Documentation discipline. The MSP should be feeding documentation back to your team, not hoarding it as job security.

If you’d rather discuss your specific situation, our team in Melbourne is happy to have a no-pressure conversation. Call 1300 028 324 or use the contact page. We’ve been doing this since 2014 and we’ll tell you honestly if co-managed isn’t the right fit.

What not to do

A few patterns we see that don’t end well:

• Hiring a junior to “help” a drowning senior. The senior now has less time, because they’re supervising the junior, and the junior can’t take work off their plate for six months.
• Buying tools instead of capacity. A new RMM platform or ticketing system doesn’t fix the problem. It just gives you better visibility into the backlog.
• Asking the team to “be more efficient.” They’re already running flat out. Telling overwhelmed people to work smarter is how you get a resignation.
• Ignoring the documentation gap. If you don’t fix it, the day Mark resigns is the day you discover what you don’t know.

How to decide

Pick a quiet week and do three things. First, sit with your IT manager for an hour and ask them honestly what they’d change if they could. Second, look at the ticket data — volume, age, recurrence. Third, look at the project roadmap and ask which things have been on it for more than six months and why.

If the answers point to “we need a person who can take ownership of this whole function long-term,” hire. If they point to “we need predictable capacity now, especially after hours,” look at co-managed. If they point to “the whole IT function is broken and we don’t have anyone capable of running it,” that’s a conversation about fully outsourced IT support.

FAQ

How do I know if my internal IT person is overwhelmed or just bad at their job?

Look at trajectory. A good person who is overwhelmed will be doing things in the right order — critical first, easy wins next — and will be honest about what’s not getting done. A bad hire will be busy on the wrong things, defensive about backlog, and surprised by problems they should have seen coming. If you’re not sure, get an outside review of the environment. The state of documentation, patching and backups will tell you quickly.

Won’t bringing in an MSP make my internal team feel threatened?

It can, if you handle it badly. The framing matters. Co-managed IT is being introduced because the business has grown beyond what one or two people can sustain — not because the internal team has failed. The good ones are usually relieved. The ones who feel threatened often turn out to be the ones quietly hoping nobody finds out what they haven’t been doing.

How much does co-managed IT cost compared to hiring?

A mid-level Melbourne technician costs around $90-110k loaded once you add super, leave, training and overheads. Co-managed engagements vary by scope, but for a 50-100 staff business expect to spend less than a full-time hire while getting after-hours coverage, multiple skill sets and no recruitment risk. The honest answer is to get specific quotes against your environment.

Will my internal IT manager lose authority if we bring in an MSP?

Not if the scope is clear. In a proper co-managed setup, the internal manager owns strategy, vendor relationships and business context. The MSP owns execution capacity, after-hours coverage, and specialist skills they wouldn’t otherwise have access to. The manager becomes more effective, not less.

How fast can we actually get relief?

Faster than hiring. A reasonable co-managed onboarding is 4-6 weeks to fully embedded, but a good MSP will be absorbing tickets and after-hours load within the first two weeks. Compare that to a 3-4 month recruitment timeline plus onboarding. For a team that’s already burnt out, that gap matters.

The honest summary

An overwhelmed internal IT team is a solvable problem, but only if you name it early. The longer it runs, the more you lose — first in projects, then in security posture, then in your best person walking out the door. Hiring, restructuring and co-managed are all valid responses. Pick the one that matches your actual situation, not the one that feels least disruptive.

If you’d like a Melbourne-based perspective on which option fits your business, the team at TechAssist is happy to walk through it. We’ve been doing this since 2014 and we’d rather tell you honestly what we’d do than win work we shouldn’t have.