IT for Multi-Generational Workplaces: From Gen Z to Boomer Staff

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.

Your sole internal IT person hands in their notice on a Tuesday afternoon. The next 90 days will quietly expose every undocumented decision, shared login, and unwritten vendor relationship they were holding together. Most Melbourne SMEs discover within a fortnight that they have no idea what their IT person actually did, and the cost of that ignorance compounds fast.

The shape of the problem

If you are running a 30 to 150-staff business in Melbourne with a single internal IT person, your operational risk is almost certainly higher than your insurer thinks it is. That person is the firewall, the documentation, the vendor relationship manager, the backup verifier, and the person who knows that the printer on level 2 has its own static IP because someone in 2019 wired it badly and nobody has fixed it since. When they resign, none of that lives anywhere else.

We have walked into this scenario more times than we can count since founding TechAssist in 2014. The pattern is consistent enough that we now treat it as a defined transition project rather than a panic. The 90-day window splits cleanly into three phases, and how you handle each one determines whether the next IT model you adopt is built on knowledge or built on guesswork.

This post walks through that window honestly. We will not pretend the handover is clean, because it almost never is. We will name the mistakes that bite later, lay out a realistic cost comparison for the three paths forward, and tell you what to do in the first 48 hours that will save you the most pain.

Week 1-2: Knowledge dump and credential capture

The clock starts the moment notice is given. Your departing IT person is, depending on the relationship, either genuinely trying to leave things tidy or already mentally checked out. Either way, the goal of the first fortnight is to extract every piece of operational knowledge from their head and every credential from their personal devices before they walk out the door.

The credential audit comes first

Before anything else, you need a complete list of every system the business uses, who owns the admin account, and where that credential is stored. In practice, most SMEs discover their IT person has been the sole holder of admin credentials to:

• The Microsoft 365 global admin account, often tied to their personal mobile for MFA
• The domain registrar (frequently a personal GoDaddy or Crazy Domains account from years ago)
• The DNS provider, which may or may not be the same as the registrar
• The firewall management console, with the vendor portal login on a Post-it note
• The NBN or fibre service account, registered to their personal email
• Backup software portals, antivirus consoles, RMM tools if they ran one
• Line-of-business application admin accounts

The MFA problem is the one that catches people. Personal phone-based MFA is the single most common landmine we find. If your departing IT person’s mobile is the second factor for your Microsoft 365 global admin, and you do not transfer that before they leave, you are one factory reset away from being locked out of your own tenant. Microsoft’s account recovery process for global admin lockouts is slow, painful, and requires documentation most SMEs cannot produce on demand.

Document the undocumented

The other priority for week 1-2 is sitting down with the departing engineer and walking through the actual environment. Not what is in the wiki, what they actually do day-to-day. The questions that produce the most value:

• What automations or scripts run on a schedule? Where do they live?
• Which vendor support contracts exist, when do they renew, and who is the named contact?
• What is the backup routine, where are backups stored, and when was the last successful restore test?
• Which servers or services are running on hardware that should have been replaced years ago?
• What workarounds exist that nobody else knows about?
• Which staff have local admin rights they should not have, and why?

A Caulfield-based legal practice we onboarded last year had their sole IT manager resign after 11 years. During the knowledge dump, he casually mentioned that the practice management database was being backed up by a PowerShell script he wrote in 2016 that ran on his personal laptop because the server scheduled task had stopped working in 2019 and he had not got around to fixing it. The firm had been one stolen laptop away from losing seven years of matter records without realising it.

Week 3-6: Vendor relationships and the ‘who pays for what’ audit

Once you have credentials and a working operational picture, the second phase is harder and less satisfying. You need to map every vendor relationship, every recurring charge, every Master Services Agreement, and every handshake deal your IT person ever made. This is the phase that tends to drag, because the information is fragmented across accounts payable, the IT person’s email folders, and the memories of long-tenured staff.

The vendor map

Start with the bank statements and the accounting system. Pull 12 months of card transactions and supplier invoices. Categorise every IT-related charge. You will find:

• SaaS subscriptions nobody uses anymore
• Hardware leases that auto-renew next quarter
• Support contracts on equipment that was decommissioned
• Domain renewals you did not know existed
• Monthly retainers to small contractors for specific systems
• Cloud bills (AWS, Azure) that have been growing 8% per quarter without anyone noticing

For each vendor, you want the named contract, the renewal date, the named contact, and the escalation path. Most SMEs find at least 5% of IT spend is going to things that no longer deliver value. For a business with $80,000 annual IT spend, that is $4,000 a year sitting in dead subscriptions.

The MSA discovery

Master Services Agreements with key vendors are often signed once, filed badly, and forgotten. When your IT person leaves, you need to know:

• What service levels are you actually entitled to?
• What are the notice periods if you want to terminate?
• Are there minimum spend commitments?
• Who has authority to raise priority support tickets?

For businesses considering a move to a managed IT services arrangement, this audit is non-negotiable. You cannot transition into a managed model cleanly without a complete picture of existing commitments. We have seen incoming MSPs surprised by 18-month telco contracts that the previous IT person signed without anyone realising.

Week 7-12: Decide the path forward

By week 7, you have credentials, documentation, and a vendor map. Now the actual strategic decision: replace, co-manage, or fully outsource. This is where most SMEs default to ‘replace like-for-like’ because it feels safest, but it is rarely the cheapest or the most resilient option.

Option 1: Replace internally

Hire another internal IT person. This is the path of least change but the highest single-point-of-failure risk. You are rebuilding the same fragile structure you just discovered the cost of. If you go this route, your new hire should inherit not only the credentials but also a contract clause requiring all admin access to use organisational MFA, all credentials to be stored in a business password vault, and all documentation to live in a business-controlled system. That is the bare minimum to avoid repeating this exercise in three years.

Realistic Melbourne salary for a competent internal IT generalist who can cover infrastructure, end-user support, and basic security is $90,000 to $115,000 including super, plus tools, training, and the productivity gap during recruitment (typically 3-4 months).

Option 2: Co-managed IT

Keep an internal person, but layer an MSP underneath them for the heavy lifting: 24/7 monitoring, after-hours coverage, escalation for complex problems, vendor management, and the security stack. The internal person focuses on what they are best at, which is usually being close to the staff and the business. This model works well for businesses with 50 to 250 staff who have a meaningful in-house IT need but not enough work to justify a team of three.

Our co-managed IT support model is designed for exactly this scenario, and it is often where businesses land when they have just lost a sole IT person and want resilience without complete outsourcing. The internal hire is junior to mid-level (so cheaper), the MSP carries the senior expertise and after-hours risk, and the business gets two layers of redundancy.

Option 3: Fully outsource to an MSP

No internal IT person. All support, infrastructure, security, and strategy moves to an MSP under a per-user fixed monthly contract. This is the right answer for most businesses under about 80 staff, and increasingly for businesses up to 150 staff who do not have specialist needs.

The economics are straightforward once you do the maths. A 60-staff Melbourne business paying $105,000 fully-loaded for an internal IT person, plus $25,000 in tools and licences they manage, is spending $130,000 a year for one person who takes leave, gets sick, and cannot cover after-hours. A per-user fixed monthly MSP arrangement for the same business typically lands between $110 and $160 per user per month depending on inclusions, which puts the spend in the $80,000 to $115,000 range with a contracted service level behind it. You also get the security stack, 24/7 monitoring, and a team rather than a person.

TechAssist runs a 24/7 NOC at our Tecoma office, which means when something breaks at 2am, somebody Australian is already looking at it. We also operate a CBD office at 575 Bourke Street, which matters if your staff are in the city and you want same-business-day on-site response across Melbourne metro. Our 13 Australian engineers cover the work that one internal person cannot, and our sub-15-minute P1 response target is contractual, not aspirational. If you want to choose an MSP in Melbourne properly, this is the question to ask: what is the contractual response time, and what happens if it is missed?

Realistic cost comparison: three paths

The numbers below assume a 60-staff Melbourne business with a typical mix of office and field workers, Microsoft 365 Business Premium, a small server footprint, and standard security needs. Adjust for your context, but the relative shape holds.

The outsourced option is cheapest on paper, but the right answer depends on the business. A manufacturer in Dandenong South with heavy line-of-business software and a real shop-floor IT footprint might genuinely need an on-site person. A professional services firm in Hawthorn with 40 staff almost certainly does not.

Offboarding mistakes that bite later

These are the recurring patterns we see in the second year after a sole IT person leaves. None of them are dramatic. All of them are expensive.

Shared admin accounts

The departing IT person had a personal admin account they used for everything. When they left, somebody changed the password but did not disable the account. Six months later, an attacker who phished those credentials in 2023 finally gets around to using them. The audit log shows the admin account was used, but nobody knows which human pressed which key. Disable departing admin accounts. Do not just rotate the password.

Personal phone-based MFA

Already covered above, but it bears repeating because it is the single most common failure mode. Every MFA factor needs to be on a business-controlled device or a business-controlled mechanism (such as a security key held by the business, or a service account authenticator app on a business device).

Undocumented automations

Scripts, scheduled tasks, Power Automate flows, Zapier workflows, all running quietly in the background, all created by the departing person, none of them documented. The first failure happens nine months later when something breaks and nobody can find the source. Audit every scheduled task on every server, every Power Automate flow in the tenant, and every connector in any iPaaS tool. Document what each does, who owns the business outcome, and what happens if it stops.

Vendor portals registered to personal emails

The Telstra account, the Microsoft partner relationship, the AWS root account, the domain registrar, all created in 2017 using a personal Gmail address because it was faster than waiting for IT to set up a shared mailbox. Hunt every one of these down before the departing person walks out. Once they are gone and the vendor only accepts identity verification via that personal email, you have a multi-month problem.

Local admin rights on workstations

Many sole-IT-person businesses run with local admin rights distributed liberally. The IT person gave it out as a workaround for software installs and never took it back. This is a security problem that needs fixing during the transition, not after, because incoming MSPs will see this as a red flag and either price it in heavily or refuse the engagement. Restricting local admin is also one of the Essential Eight controls that the ACSC has been pushing for years.

What to do in the first 48 hours

If you are reading this because your IT person just resigned, here is the order of operations for the first two days. Everything else can wait.

1. Change the Microsoft 365 global admin password and MFA factor. Today. Use a business-owned phone or hardware token.
2. Add a second global admin account belonging to a director, with separate MFA, as an emergency access account.
3. Pull a list of all admin role assignments in Microsoft 365 and document which humans hold which roles.
4. Identify the domain registrar and DNS provider and confirm the business has account control. If not, start the recovery process immediately.
5. Engage a transition partner if you do not have internal capacity for the next 11 weeks of work. This is not a normal-business-week task.

If you want help running this transition cleanly, that is the bread and butter of our Melbourne MSP practice. We have done it dozens of times. The pattern is repeatable. The mistakes are predictable. The 90 days will pass either way.

Frequently Asked Questions

How long should the notice period be for a sole IT person?

Contractually, whatever your employment agreement says, usually four weeks. Practically, you want to be in a position where you could survive a one-day departure if the relationship turned sour. That means documentation, credential capture, and a transition plan ready to execute. If you only have the standard notice period and no plan, four weeks will not be enough.

Should we let the departing IT person help us choose the replacement?

Generally, no. Their incentives and the business’s incentives are not aligned. They may favour a friend, or push toward a model that protects their professional reputation rather than what fits the business. Use the departing engineer for knowledge transfer, not for vendor selection.

What if the departing person was a contractor, not an employee?

The risk profile is similar but the legal lever is different. Contractors usually have weaker IP and confidentiality protections by default unless the contract was written carefully. Check the contract for credential ownership, work product ownership, and data handling clauses. If the contractor was using their own tooling (their RMM, their backup software, their monitoring), you need to migrate off that tooling before they leave, not after.

Is co-managed IT just outsourcing with extra steps?

No, and this is a common misconception. Co-managed works because the internal person handles the relationships, the business knowledge, and the ground-level support, while the MSP handles the depth, the after-hours, the security stack, and the senior expertise. The internal person is the face. The MSP is the backbone. It works for businesses that have enough IT work to keep one person busy but not enough to justify a team.

How does the Essential Eight fit into all of this?

The Essential Eight is the ACSC’s baseline cybersecurity framework, and it is becoming a de facto expectation for Australian SMEs working with government, financial services, or healthcare clients. A sole IT person rarely has the bandwidth to implement and maintain all eight controls properly. The transition out of a sole-IT model is a natural moment to assess your cybersecurity posture against the Essential Eight and pick a path forward that closes the gaps.

How quickly can an MSP take over from a departing internal IT person?

For a clean transition, six to eight weeks from contract signature to full handover is realistic. We have done faster in emergency scenarios, but the work suffers. The first two weeks are discovery and credential transfer, the next two weeks are tooling deployment and policy alignment, and the final two to four weeks are co-running while the departing person is still available for questions. If you are starting that conversation, do it the week the resignation lands, not the week before the person leaves.

Week 1 of a co-managed IT engagement is mostly listening, counting and writing things down. We audit the environment, capture credentials, transfer documentation from your internal IT person, and get a RACI matrix signed. No big changes, no tool rollouts. The goal is a true picture of what you actually have, not what the last vendor said you had.

That paragraph is the short answer. The rest of this piece is the long one — a week-by-week playbook of what the first 30 days of co-managed IT onboarding should look like for a Melbourne SME, what goes wrong, and how to tell whether your new partner is doing it properly or just collecting a monthly fee.

We’ve run this onboarding sequence dozens of times at TechAssist since 2014, mostly for businesses between 30 and 200 staff across Melbourne. The pattern below is what we’ve settled on after enough painful lessons to know which corners can’t be cut. If your engagement is starting next month, print this out and use it as a checklist against whatever your MSP proposes.

What co-managed IT onboarding actually is (and isn’t)

Quick definition so we’re aligned. Co-managed IT means your internal IT person or small team keeps running day-to-day, and an external MSP plugs in to handle specific gaps — usually 24/7 monitoring, after-hours support, escalations, project capacity, and the unsexy compliance and documentation work. It’s not full outsourcing. It’s not staff augmentation. If you’re not sure which model suits you, our co-managed vs managed vs internal IT comparison breaks down the differences in plain terms.

Onboarding is the bridge between signing the contract and the partnership actually working. Done well, it takes four weeks and ends with both teams operating as one. Done badly, it stretches to six months and never really finishes — the MSP is firefighting tickets they don’t understand because nobody documented anything, and your internal lead is quietly furious because they’ve been answering the same questions for ninety days.

The thirty-day target isn’t arbitrary. After 30 days you should be at steady-state: tickets flowing, monitoring green, runbooks written, the first quarterly business review (QBR) scheduled. If you’re not there by day 30, something has gone wrong upstream — usually in week 1.

The 30-day playbook at a glance

That’s the skeleton. Now the meat.

Week 1: Discovery and scoping

The opening week is unglamorous and easy to skip. Don’t skip it. Everything that follows depends on what you find in the first five working days.

The environment audit

On day one we walk the environment with your internal IT lead. Not remotely. In person where possible, even if it’s a half-day in a Hawthorn office. We want to see the comms cabinet, count the switches, photograph the UPS labels, find the cabling that runs through the ceiling void that nobody documented. Remote-only audits miss the patch panel that’s held together with cable ties and hope.

The deliverable from the audit is a written inventory covering:

• Every server (physical and virtual), with OS, role, owner and last-patched date
• Every endpoint count by device class, broken down by warranty status
• Network gear — firewalls, switches, APs — with firmware versions and support contract end dates
• SaaS tenants — Microsoft 365, Google Workspace, line-of-business apps — with licence counts and admin accounts
• Backup targets, retention policies, last verified restore date
• Internet links, static IPs, DNS hosting and where the domain registrar sits

If your MSP doesn’t ask for the last verified restore date, that’s a red flag. Backups that haven’t been tested aren’t backups. They’re hope.

Credentials capture

This is where most onboardings stall. Your internal IT person — let’s call him Dave — has accumulated passwords over four years. Some are in a KeePass vault, some are in his head, some are on a Post-it under his keyboard, and a few belong to a previous employee whose Microsoft 365 account technically still has Global Admin.

The MSP needs everything moved into a shared, audited password vault before week 2. Not Dave’s personal KeePass. A vault both teams can access with role-based permissions and full audit logging. We use a hosted IT documentation platform with credential management built in; your MSP will have their own. The point is shared, audited, encrypted.

Here’s what often goes wrong: Dave doesn’t want to share the passwords. Sometimes it’s protective — he’s worried about his job. Sometimes it’s just years of muscle memory around being the sole custodian. Either way, it has to be addressed by the business owner directly. The MSP can’t force it. We’ve had week 1 stretch to three weeks because a single internal lead wouldn’t hand over the firewall admin password, and the whole project sat there idling.

The fix is a frank conversation, framed around resilience. If Dave gets hit by a tram on the Lygon Street tracks tomorrow, the business needs to keep running. Co-managed IT is the insurance policy, not the replacement.

Documentation transfer

Whatever Dave has — Visio diagrams, OneNote pages, a folder of Word docs called “IT Stuff” — it all gets transferred and reviewed. Most of it will be out of date. That’s fine. We’re not auditing Dave’s documentation hygiene; we’re capturing institutional knowledge before it walks out the door.

Things we look for that are nearly always missing:

• Network diagram showing actual VLAN topology, not the one from 2019
• List of which line-of-business app talks to which database, on which server, on which port
• Vendor contacts with account numbers — internet provider, hardware supplier, line-of-business software vendors
• Recurring scheduled tasks (the script that runs every Sunday night that nobody understands)
• The actual office Wi-Fi password

RACI matrix sign-off

The most important week 1 deliverable, and the one businesses skip most often. A RACI matrix lists every category of work — patching, user onboarding, after-hours P1 response, M365 licence changes, backup verification, project work, vendor liaison — and for each one assigns Responsible, Accountable, Consulted and Informed roles between you and the MSP.

Without it, scope creep starts on day 8. We had a Box Hill manufacturing client where week 2 turned into a “could you just have a look at this” parade because nobody had written down who owned what. Their internal IT lead burned out within six months and we had to renegotiate the agreement. A signed RACI in week 1 would have prevented all of it.

A good RACI is boring. Three pages of “MSP responsible, internal IT consulted” rows. If it’s exciting, something’s wrong.

Week 2: Tooling rollout

With the audit complete and the RACI signed, week 2 is when the MSP’s tooling goes in. This is the visible part of onboarding and the part most clients judge us on. It’s important, but it’s only the middle act.

RMM deployment

Remote Monitoring and Management agents go on every server and endpoint. The deployment itself is straightforward — a GPO push or Intune deployment, depending on your environment. The harder part is the post-deployment tuning. Out of the box, every RMM screams about everything. By end of week 2 it should be tuned to your environment: warnings on the things that actually matter, silence on the things that don’t.

Ask your MSP what their first-week alert volume looks like. If they tell you “five hundred alerts a day, we’ll tune it later” — that’s a tooling team that doesn’t tune. If they tell you “we expect noise for 48 hours then it should drop below 30 actionable alerts a day” — that’s a team that knows what they’re doing.

EDR rollout

Endpoint Detection and Response goes on the same agents. We typically run in monitoring-only mode for the first week, then flip to blocking once we’ve baselined what’s normal in your environment. The Camberwell legal firm we onboarded last spring had a custom internal app that EDR initially flagged as malware. Two days of monitoring told us it was legitimate, we wrote an exclusion, and we never heard from it again. Had we gone straight to blocking on day one, their fee earners would have been locked out of their case management system.

EDR also needs to be connected to a 24/7 monitoring centre. Detection without response is just a noisier RMM. Our NOC at Tecoma watches EDR alerts for every client around the clock, with a sub-15-minute target response on P1 incidents. If your MSP doesn’t operate (or contract to) a true 24/7 NOC, you don’t have 24/7 cover regardless of what the SLA document says.

Backup monitoring

Your existing backup solution — whatever it is — gets connected to monitoring. We don’t usually rip and replace backup tooling in week 2; that’s a project for month two or three. Week 2 is about visibility. Are jobs running? Are they completing? When was the last successful restore test?

One of our Ringwood clients arrived with backups that had been “running fine” for two years according to their previous vendor. First week of monitoring revealed three of seven jobs had been silently failing since the previous Christmas. The vendor had been ignoring the alert emails. This is exactly the kind of thing co-managed IT catches in week 2.

NOC enrolment

By Friday of week 2, your environment is enrolled in the MSP’s NOC. That means 24/7 eyes on monitoring, with documented escalation paths back into business hours support. Test it. Genuinely. Pick a Saturday morning, simulate a server going offline, see what happens. If you don’t get a phone call within fifteen minutes, you’ve learned something important before it matters.

Week 3: Runbook writing

Week 3 is where co-managed IT separates from break-fix outsourcing. A break-fix vendor stops here — tools are in, tickets are flowing, what more do you want? A co-managed partner spends week 3 writing down how your specific environment is meant to operate.

BAU runbooks

Business as usual procedures get documented. The deliverables are short, practical documents — usually one page each — covering things like:

• New starter provisioning end-to-end (M365 licence, group memberships, line-of-business app accounts, hardware allocation, induction checklist)
• Leaver offboarding (account disable timing, mailbox conversion to shared, OneDrive handover, MFA token revocation, asset return)
• Password reset for the CEO’s PA (specific authentication checks because executives get targeted)
• VPN access request and approval workflow
• Standard hardware build and imaging procedure

These runbooks live in shared documentation. Both teams update them. They’re owned by the MSP’s service delivery manager but the internal IT lead has edit rights. If your MSP keeps runbooks in a vault you can’t access, you’ve recreated the original lock-in problem you were trying to solve.

After-hours playbooks

The after-hours playbook is what the NOC reads at 2am when something breaks. It needs to be opinionated. “If the primary firewall is unreachable, do X, then Y, then call Z.” Not “investigate and escalate appropriately.” The whole point of co-managed IT is that the NOC engineer at 2am — who has never met your team — can act decisively because the playbook tells them exactly what your business considers acceptable risk.

Three things the after-hours playbook must include:

1. Reboot authority — what services can the NOC restart without calling anyone, and which ones need human approval no matter what time it is?
2. Escalation contacts in priority order, with both mobile and alternate numbers
3. Communication rules — when does the business want a phone call versus a text message versus an email-tomorrow?

We’re firm with clients on this: if you don’t give the NOC reboot authority for non-critical services, you’re paying for 24/7 cover and getting a 24/7 paging service. Different things.

Escalation tree

Published, visible, dated. Both teams should know that P1 incidents go to the internal IT lead first, then to the operations manager, then to the business owner. P2 follows a different path. P3 doesn’t wake anyone up. The escalation tree gets reviewed and re-signed at every QBR.

Week 4: Shakedown and the first QBR

The final week of onboarding is about live testing and setting up the steady-state cadence.

Live ticket testing

By week 4, real tickets are flowing. We deliberately introduce a few synthetic ones to test the full pipeline — a fake password reset, a simulated phishing report, a planned “service down” drill. The goal is to find the gaps in the workflows we built in weeks 2 and 3 before a real incident finds them for us.

Failover drill

If your environment includes any kind of failover — secondary internet link, virtualised server cluster, cloud-hosted backup of an on-prem database — we test it during week 4. Pull the cable. See what happens. The Footscray distribution client we onboarded last year discovered during their week 4 drill that their secondary internet link had been incorrectly configured for eighteen months. The failover had never worked. They’d have found out the hard way during the next storm.

QBR preparation

The first Quarterly Business Review happens 90 days after go-live, but the pack starts coming together in week 4. The QBR pack should cover:

• Tickets raised, resolved, escalated — broken down by category
• SLA performance against contract
• Open security or compliance findings from the week 1 audit, with remediation status
• Recommended projects for the next quarter, ranked by business value
• Budget tracking against your IT operating budget

A useful QBR is opinionated. The MSP should have a view on what you should do next, with reasoning. If your QBR is a slide deck of green ticks and nothing else, you’re getting account management, not strategic advice.

The 90-day plan

Week 4 closes with a signed 90-day plan listing the projects the MSP and internal IT will tackle together. Usually 3-6 items. Things like “migrate file server to SharePoint,” “replace ageing firewall,” “implement conditional access policies in M365.” Each one has a budget, an owner and a target completion date.

A real example: a 90-staff engineering consultancy in Cremorne

We onboarded a structural engineering consultancy in Cremorne last quarter — 90 staff, two offices, one internal IT manager who’d been there nine years and was three weeks from going on long service leave. The brief was specific: get fully operational before he walked out the door.

Week 1 went mostly to plan. The audit surfaced two unsupported Server 2012 R2 boxes still running production workloads, a Hyper-V cluster with a failed disk that nobody had been alerted to, and an Active Directory with 47 stale user accounts including three former IT contractors with Domain Admin.

Week 2 was where it got interesting. The internal IT manager — entirely reasonably — wanted to be the one to flip every switch. We worked around him, scheduled deployments during his preferred hours, and accepted the slower pace because the alternative was a worse handover. Don’t underestimate this. Co-managed IT is a relationship, and the internal lead’s psychological investment matters.

Week 3 we hit a scope creep moment. The CFO asked whether we could “just have a quick look” at why the M365 e-discovery search wasn’t returning results, which turned out to be a configuration project worth about two weeks of engineering effort. We declined to absorb it into onboarding, scoped it as a separate project, and got it approved as the first item on the 90-day plan. That’s what the RACI is for.

Week 4 the failover drill found that their secondary internet link’s BGP advertisement had a typo in the AS path, so failover would have black-holed traffic. Fixed inside the drill window. The internal IT manager went on long service leave on day 31. Steady-state for the past four months has been clean.

What good MSPs do differently in onboarding

If you’re comparing MSPs and trying to read between the lines of their onboarding pitches, here’s what to listen for.

They want to talk to your existing IT person before signing

A serious MSP wants a 30-minute call with your internal IT lead during the sales process, not after. They’re trying to understand whether the handover will be co-operative. If your prospective MSP shows no interest in your incumbent until the contract’s signed, expect a difficult onboarding.

They have a written onboarding methodology

Ask to see it. If they email you a Visio diagram and a six-page document, good sign. If they wing it from a sales deck, less good. Our methodology lives in the same documentation system clients use post-onboarding — they can see exactly what we’re going to do because we’re going to ask them to use the same system afterwards.

They quote a per-user fixed price for steady-state

Onboarding work is project-priced. Steady-state should be per-user per-month with a clear inclusions list. If your MSP quotes hourly for everything post-onboarding, your costs will balloon unpredictably the moment you actually need them. Our co-managed IT pricing breakdown walks through how this should be structured for Australian SMEs.

Their engineers answer the phone

Not a call centre, not a triage queue with three levels before you reach someone who can help. TechAssist runs 13 engineers, all Australian-employed, and the person who picks up your P1 call at 11pm can usually fix the problem themselves. That model has limits at scale, but at SME scale it’s the right one. Our managed IT services page lays out the staffing model in more detail.

The most common onboarding failures (and how to avoid them)

After eleven years of doing this, the failure modes are pretty consistent.

The incumbent won’t share credentials. Addressed above. Requires executive sponsorship and a frank conversation about resilience.

The RACI doesn’t get signed. Everyone agrees in principle, nobody puts ink on paper, and by week 3 the scope is whatever the loudest person says it is. Insist on signature before week 2 starts.

The MSP deploys tooling without tuning it. Visible in week 2 alert volumes. If your inbox is on fire by Friday of week 2, the MSP isn’t doing the configuration work.

Runbooks get skipped to “save time.” Week 3 is the easiest week to compress because it’s all writing. It’s also the week that pays the biggest dividends in months two through twelve. Don’t let it get squeezed.

The first QBR doesn’t happen. If 90 days come and go and nobody’s booked the QBR, the engagement has already drifted into break-fix territory. Push for the date in week 4.

Scope creep on day 8. The “could you just have a look at” parade. Every co-managed engagement faces this. The answer is “yes, and here’s the scoped quote” — never “yes, we’ll absorb it.”

What this should cost

Onboarding for a 50-150 staff Melbourne business typically lands between $8,000 and $22,000 as a one-off project, depending on environment complexity. Steady-state per-user pricing then sits in the range we’ve documented in our pricing guide. You can also see our standard SLA terms on the pricing and SLA page.

What you should not see is a low onboarding fee paired with hourly steady-state rates. That’s the model where MSPs make their money on the surprise invoice in month three. Per-user fixed monthly with a clear inclusions list is the only model that aligns incentives properly.

Where to from here

If you’ve just signed a co-managed IT agreement, share this article with your new MSP and ask them to walk you through their version of each week. If their methodology looks materially different, get them to explain why. Different isn’t wrong — but it should be defensible.

If you’re still evaluating, our overview of co-managed IT support covers the broader engagement model, and the co-managed IT for Melbourne SMEs piece goes deeper on why the internal-plus-external structure works for businesses in our market.

If you want to talk through your specific environment, the team at TechAssist is on 1300 028 324, or use the form on our contact page. We’re based in Melbourne, our NOC runs out of Tecoma in the Dandenong Ranges, and we’ve been doing co-managed IT for Australian SMEs since 2014. No call centres. No overseas escalation. Just engineers who answer the phone.

FAQs

How long should co-managed IT onboarding actually take?

Four weeks for a typical 30-200 staff Melbourne business. Longer if your environment is unusually complex (multiple sites, heavy compliance requirements, line-of-business applications with no current documentation) or if there’s friction with the incumbent IT staff. If your MSP is quoting more than six weeks for a standard SME environment, ask what’s driving the extra time — it’s usually a sign their process isn’t tight.

Do we need to replace our existing tools during onboarding?

No. Week 2 is about getting visibility, not ripping and replacing. If your existing backup, EDR or RMM is genuinely fit for purpose, a good co-managed partner will connect it to their monitoring and leave it in place. Tool replacements get scoped as separate projects in the 90-day plan, with proper cost-benefit analysis. Anyone who tries to replace everything in week 2 is selling licences, not service.

What if our internal IT person resists the engagement?

Common, and usually fixable. Most resistance comes from job insecurity rather than genuine disagreement. A clear RACI matrix that shows the internal lead remaining responsible for strategic and relationship work — while the MSP absorbs the monitoring, after-hours and overflow — almost always wins them over within the first month. If resistance persists past week 2, that’s an executive conversation, not an IT one.

Will we get the same engineer every time?

For day-to-day work, you’ll get a small team of two to four engineers who know your environment, not a random round-robin from a queue. After-hours and P1 incidents go to whoever’s on the NOC roster, which is why the runbooks matter — they make sure any of our 13 engineers can act decisively on your environment even if they’ve never been on-site. Sub-15-minute P1 response is the standard we hold ourselves to.

What happens if onboarding falls behind schedule?

It happens. About one in five engagements slip by a week, usually because of credential or documentation friction in week 1. A serious MSP will flag the slip immediately, explain the cause, and adjust the plan rather than pretending everything’s on track. The worst outcome is silent slippage — week 4 arrives and nobody’s done the runbooks, but the invoicing has switched to steady-state. Insist on weekly status updates during onboarding and don’t let week 4 close without the deliverables checklist signed off.