When businesses switch IT providers, the new team inherits whatever the previous one left behind. These are the real stories from environments we have taken over: what we found, what it cost them, and how we turned it around.
The first thing we do when we take over a new client’s environment is audit it.
Not a surface-level scan. A proper look — hardware, software, security configuration, backup integrity, account access, licensing compliance, documentation. We have a structured process for it, and we have run it enough times now to know roughly what we are going to find.
The environments we inherit from previous providers fall into two categories. The first is a genuinely well-managed system that the client is leaving for reasons unrelated to quality — a change in business size, a geographic move, a relationship issue. These are rare and they are a pleasure to take on.
The second category is an environment that has been neglected, mismanaged, or in some cases actively botched. These are the majority. And the stories from inside them are the reason I believe so strongly in doing this work properly.
The Accounting Firm With No Working Backups
We took on an accounting firm — twenty-two staff, suburban Melbourne, a busy practice with several hundred client files on a shared server. They had been with their previous IT provider for about four years.
Our audit found that the backup system had last completed successfully eleven months earlier.
Let that land for a moment. Eleven months. Nearly a year of a small accounting firm running with live client data, trust account records, and financial documents that had no verified backup copy.
The backup software had failed silently. An error in the configuration meant that the backups were running — completing, even reporting as successful — but the data being written was corrupt. No one had tested a restore. The monitoring that should have caught the failure had not been set up correctly. And in four years, no one from the previous provider had run a restore test on this environment.
We found this during our initial audit, before we had even formally started the engagement.
The practice principal went pale when I explained it. He asked how long they had been at risk. I told him honestly: probably the better part of a year. A server failure, a ransomware attack, a corrupted database during a software update — any of it, at any point in those eleven months, would have been catastrophic. The firm might not have survived it.
We fixed the backup configuration, tested restores, and implemented monitoring with actual alerting that required a human response when it triggered. Three weeks later, we had clean backups running nightly with verified restores. It should never have been allowed to reach the state we found it in.
The Law Firm Running on a Dead Server
A different law firm — though as I have written elsewhere, law firms show up disproportionately in these stories — with seventeen staff and a server that was seven years old running Windows Server 2012 R2. Which, for context, had been out of Microsoft support for over two years by the time we took over the environment.
The server was the primary file server for the entire practice. Every document, every case file, every precedent, every piece of client correspondence for seventeen years of practice history lived on this machine. The machine that was running an unsupported operating system and had not had a hardware health report run on it in anyone’s recent memory.
When we ran diagnostics, we found the RAID array had a degraded drive. One drive had partially failed. The RAID was still operational — still protecting the data — but it was operating without redundancy. A second drive failure at any point would have taken the entire array down.
We had to have a very uncomfortable conversation. I explained what RAID is, what degraded means, what the exposure was. I explained that we could not take responsibility for the environment until the hardware was replaced and the operating system upgraded to something supported — because managing a system in that state was not something we were willing to do. The liability and the risk were both unacceptable.
The firm authorised the work within 48 hours. Urgency has a way of clarifying decision-making. We replaced the server, migrated everything to a current platform, and that environment has run cleanly ever since.
The previous provider, it turned out, had flagged the server age in a review document eighteen months earlier. The recommendation had been noted and not acted on. That is a different problem — and one I will write about separately — but the provider had also stopped raising it. At some point they had decided that if the client was not listening, they would stop advising. That is not acceptable either.
The Medical Practice With Staff Sharing Credentials
This one still bothers me.
A medical practice — GP clinic, four doctors, nursing staff, reception, the full picture — where we discovered during the onboarding audit that staff were sharing a single Windows login to the practice management software.
One username. One password. Circulated to all staff via a note stuck on the inside of a drawer at the reception desk.
In a medical environment, this is not just a security issue. It is a compliance issue with real regulatory consequences. The Privacy Act requires that access to health records be auditable — that you can establish, with evidence, who accessed what information and when. A shared credential produces exactly zero audit trail. You can see that something was accessed. You have no idea who accessed it.
We had to explain this at some length, because the practice had been operating this way long enough that no one in the building had thought to question it. It was just how they did things. The previous IT provider had set it up this way — we could see the account in the system, created by them years earlier — and either had not understood the compliance implications or had decided the convenience argument outweighed them.
We rebuilt the access model from scratch. Individual accounts for every staff member, role-based permissions, proper audit logging, password manager deployment so that individual credentials did not become the “write it on a sticky note” problem they had been trying to avoid in the first place.
The practice owner was mortified when we explained the exposure. She had been in business for twelve years trusting that her IT setup was compliant. It had not been, for most of that time.
The Manufacturer With a Decade of Unpatched Software
A manufacturing business in the eastern suburbs, forty staff, a combination of office and factory floor users. Their IT environment was a museum.
We found:
- Workstations still running Windows 7, which had been out of support since January 2020.
- Core business software running on a version that was three major releases behind current, with known unpatched vulnerabilities.
- A network with no segmentation — factory floor devices on the same flat network as the finance workstations and the server infrastructure.
- A firewall that had last had its firmware updated in 2019.
- No endpoint detection and response tooling — just legacy antivirus that had not been renewed and was running on outdated definitions.
This was not the result of one bad decision. It was the accumulation of years of deferred maintenance. Probably a combination of an IT provider who had stopped pushing for remediation and a business owner who had been happy to hear that everything was fine.
Nothing was fine. The environment was comprehensively exposed.
We scoped a remediation programme across twelve months. Prioritised by risk: the unpatched endpoints first, then the network segmentation, then the firewall, then the software currency. We presented it in plain language with a business risk explanation for each item rather than a technical specification, because the decision-maker was not technical and deserved to understand what he was actually approving.
He approved the full scope. Twelve months later, the environment was unrecognisable — modern, monitored, properly segmented, with security tooling that would actually catch something if it needed to.
His comment at the end of the programme: “I didn’t know it was this bad. I trusted that someone was looking after it.”
Someone should have been.
What These Stories Have in Common
The environments I have described above were not neglected because the businesses did not care. They were neglected because the businesses trusted their IT providers to tell them when things were wrong and to advocate strongly when they were not.
In most cases, either the advocacy had stopped, had never started, or was being delivered in technical language that the business owner could not act on. The result was the same: years of accumulated risk that the business had no visibility into.
There is a version of IT support that is reactive, ticket-based, and oriented toward keeping things superficially stable without engaging with the underlying health of the environment. That version is cheaper to deliver. It is also, as these stories demonstrate, genuinely dangerous to the businesses receiving it.
The triumphs — and there are triumphs in each of these stories — came from the same place: a business that, once given clear information about their actual situation, acted on it. None of these clients knew what they were inheriting from their previous providers. Once they knew, they moved.
The audit is not the most exciting part of what we do. It is the most important part. It is the thing that makes everything else possible.
Concerned about what might be lurking in your environment? Start with a conversation.
