Sydney · Bella Vista · Western Sydney
Cloud Migration for Sydney Small Businesses
A migration that finishes on paper and leaves half the team on the old system has not finished. The verification is the work.
What you get
- A written plan naming what moves, what stays, and why
- Staged cut-over rather than a weekend of hoping
- Verified from outside the server, not from the configuration file
- A rollback position that exists before the cut-over, not after
What you are actually deciding
Before the quote. None of this is about us.
Lift and shift is cheaper to do and dearer to run
Moving a server as-is gets you off the hardware fastest and keeps the cloud bill roughly proportional to what you had. Re-platforming costs more up front and is what actually reduces the monthly spend, because it lets you switch things off when nobody is using them. Choosing the cheap option knowingly is fine. Choosing it by default is where cloud bills come from.
Most of the data does not need to move
Every migration finds years of files that must be kept and will never be opened. Moving them into the same expensive tier as live data is the single most common way a migration ends up costing more per month than the server it replaced. Sorting what is live from what is archive is unglamorous and usually pays for itself in the first quarter.
The cutover weekend is the smallest part
The work that decides whether a migration goes well happens weeks earlier: the inventory of what actually connects to what, the licences that are tied to hardware, and the one integration nobody documented. A migration that fails on the weekend usually failed at the inventory.
Why us, specifically
Every claim below is something we did to our own systems and can show you.
We migrate our own production systems
A Mautic 5 to 7 migration in Docker, done on our own marketing stack rather than a client’s. The post-mortems are published.
Verification is a step, not an assumption
We have published what happens when it is not: a redirect rule that sat in configuration for months, deployed cleanly every time, and had never once fired.
A worked example
Migrating Mautic 5.2.9 to 7.1.2 across two majors, with 45,522 contacts live
Our own marketing automation platform had sat two major versions behind for the better part of a year. We moved it, in production, and published what went wrong on the way.
- 5.2.9 → 7.1.2 versions crossed
- 45,522 contacts migrated
- 90, cleanly doctrine migrations run
- None data corruption
Questions we get asked
- How long does a cloud migration take for a small business?
- Typically two to six weeks depending on how much data moves and how many systems depend on each other. The planning is usually longer than the cut-over, which is the correct way round.
- Will we lose access during the move?
- A staged migration keeps the old system available until the new one is verified. If a cut-over needs downtime we schedule and announce it rather than discovering it.
- What if the migration goes wrong?
- There is a documented rollback position agreed before the cut-over. If it is needed we use it — that is what it is for.
Talk to someone who will answer
We are in Bella Vista. Tell us what is not working and we will tell you whether we are the right people to fix it.
Get a Quote