Switching MSPs: The 90-Day Migration Playbook for Melbourne SMEs

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

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

The three decisions you settle before day zero

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

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

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

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

2. The transition window

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

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

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

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

Your business should own:

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

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

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

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

What to demand from the outgoing MSP

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

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

Vendor relationship transfers

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

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

The “who do I call now?” comms plan

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

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

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

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

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

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

Backup and DR migration

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

The order we use:

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

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

Monitoring and ticketing platform switch

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

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

Security baseline reassessment

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

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

A concrete example

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

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

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

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

SLA verification with real tickets

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

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

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

Final removal of outgoing MSP access

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

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

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

The post-mortem with the new MSP

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

Red flags from outgoing MSPs

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

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

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

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

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

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

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

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

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

FAQ

How long does switching MSPs actually take?

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

Will my staff be without IT support during the switch?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The geography problem nobody costs out properly

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

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

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

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

What “same-day on-site” actually means

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

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

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

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

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

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

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

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

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

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

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

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

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

The outer-east-only MSP makes sense when:

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

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

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

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

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

The comparison looks something like this:

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

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

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

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

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

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

Parking, meeting rooms and the unglamorous logistics

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

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

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

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

The Sydney-pretending-to-be-Melbourne problem

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

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

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

What to actually ask when you’re evaluating an MSP

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

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

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

Where TechAssist sits in all this

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

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

Frequently asked questions

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

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

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

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

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

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

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

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

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

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

The short version

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

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