alt="Helping Clients with Cost Pressures — Cloud365 Australia blog article"
width="800" height="460"
loading="eager">
When a manufacturing business in Victoria first called us, the conversation went like this: "We've got custom inventory software running on a server that's probably ten years old. It lives in the warehouse. One day it's going to die and we're going to lose everything. What do we do?"
It's a conversation we have often. The hardware is old — genuinely old, the kind that was enterprise-grade when it was new and has been running on borrowed time for years. The software is business-critical. Nobody internally is really qualified to manage it. And the backup situation, when you dig into it, is a USB drive that was last tested at some point nobody can quite remember.
This article walks through exactly what happened with that customer — the assessment, the migration, the cutover, and what their environment looks like today — because the story is representative of what most Australian businesses in this situation actually experience.
The situation before we got involved
The manufacturing business runs 28 staff. Their custom inventory management system is used by everyone from warehouse staff logging stock movements to the owner reviewing orders and margins. It runs all day, every day. When it goes down — which happened three times in the previous year, twice for hardware reasons — work stops.
The backup situation deserves special mention, because it's more dangerous than most business owners realise. Having a scheduled backup is not the same as having a working backup. A backup that has never been tested is a hope, not a recovery plan. When we asked whether the USB drive backup had been tested — meaning someone had actually tried to restore the system from it — the answer was no. Not once.
Untested backups are one of the most common causes of data loss during a crisis. Many businesses discover their backup was corrupted, incomplete, or based on an outdated configuration only when they actually need it. By then it's too late.
What the assessment looked like
The first step was a conversation — not a technical audit, just a conversation. What does the software do? Who uses it and when? What are the peak load periods? Is there a developer we should be talking to? What's the plan if the server fails tomorrow?
From there we reviewed the server configuration and the application itself — understanding the database engine, the application dependencies, the network configuration, and what migration would involve technically. The developer who built the system, based in Brisbane, was brought into the conversation at this point. He'd been involved in one of the previous outages and was receptive to working with us on the migration.
After assessment, we provided a fixed-price proposal covering the full migration and the ongoing managed service. The monthly fee was 54% less than what they were previously spending across hardware maintenance, ad-hoc IT support, and software licensing — with significantly more included.
The migration process — what actually happened
We built and configured the destination environment in our Melbourne data centre before touching anything at the client's end. The server was provisioned, the operating system configured, the backup system set up, the monitoring and security stack deployed. When we migrated the application, it had a fully operational home to land in.
Data migration took place over two days, running the old and new environments in parallel. During this period:
- All live data continued to be written to the original server — operations were unaffected
- We migrated and synchronised the data to the new environment, then verified integrity at the database level
- The developer reviewed the application configuration in the new environment and confirmed it matched the production behaviour
- The business owner and their warehouse manager did a walkthrough of the new system from their end
Nothing went live until the client gave explicit sign-off. This is non-negotiable for us — we do not proceed to cutover until the customer has confirmed the new environment works as expected.
The most important thing about a migration is that your existing system stays live and untouched until after the new environment is tested and you've given us the green light. There is no reason to accept risk you don't have to accept.
Cutover — a Saturday morning, 3 hours
Cutover was scheduled for a Saturday morning — specifically because end-of-week stock counts happened Friday afternoon, making Saturday morning the lowest-risk window before the next operational cycle on Monday.
The process took three hours. DNS was updated, access credentials were distributed, the warehouse manager did a final test of every workflow they use in the application, and we stayed on the call throughout. By 11am on Saturday, the system was live in the new environment and the old server was powered down and left accessible as a read-only safety net for the following two weeks.
"We spent years worried about that server going down and losing everything. Now I don't think about it at all — that's exactly what I wanted."
— Business owner, manufacturing, VictoriaOn Monday morning, staff came in and logged into the system as normal. Most didn't notice anything had changed. Two staff members asked why the login screen looked slightly different — the URL had changed. That was the extent of the disruption.
What the environment looks like today
Eight months on, the customer has had zero unplanned outages. Our monitoring caught one issue in that period — a disk filling up on a schedule that wasn't optimal for their growth in data — and resolved it before it ever caused a problem visible to the business.
Backups run hourly to local storage and daily to a geographically separate remote location. We tested a full restore at the three-month mark as part of our standard practice. The recovery time from backup was 47 minutes — documented, known, and communicated to the business owner.
The developer in Brisbane now has direct access to our technical team when he needs to make changes to the application. We coordinate the infrastructure side of any changes he makes, and he handles the application code. The arrangement works cleanly because everyone knows their lane.
What to take away from this
If your situation resembles the one described in this article — older hardware, critical software, uncertain backup status — we're happy to have an initial conversation at no cost. Tell us what you're running and where, and we'll give you an honest assessment of what a migration would involve.