Four projects account for most of the SQL Server work Australian organisations commission: a version upgrade, a platform migration, an Always On availability group build, and a move to Azure SQL Managed Instance. They share a shape, and they share the ways they go wrong.
This is what each involves in practice, and what actually drives the cost.
The sequence that does not change
Whatever the project, the order is the same, and skipping a step does not save time — it moves the time to cutover night, where it costs more.
- Assess. Inventory, dependency analysis, and the compatibility questions that constrain everything downstream.
- Design. Target architecture against your actual recovery point and recovery time objectives, not against a reference diagram.
- Rehearse. A dry run against a copy of production. This is the step that gets cut, and it is the step that finds the problems.
- Cut over. Inside an agreed window, against a rollback plan that has been executed in test.
- Verify and hand over. Confirm against the acceptance criteria agreed before the work started, then a runbook the team can operate without the people who built it.
Version upgrades
The engine upgrade is the easy part. The work is in what surrounds it.
Compatibility level is the decision people underestimate. Upgrading the instance does not change a database's compatibility level, and raising it changes the query optimiser's behaviour — which changes execution plans, which changes performance, sometimes sharply and in both directions. The safe sequence is to upgrade the engine, leave compatibility level alone, confirm stability, then raise it deliberately with Query Store capturing plan regressions so you can force a previous plan if something degrades.
Deprecated features are the second source of surprise. A 2016-era application may still use constructs that later versions removed. These are discoverable in advance, and they are only ever discovered late when nobody looked.
Vendor certification constrains the answer more often than anything technical. If your ERP vendor certifies SQL Server 2019 and not 2022, that is the decision made, regardless of what the lifecycle dates argue for.
On targets: SQL Server 2022 is supported to 12 January 2033. SQL Server 2019 is supported to 9 January 2030, but its mainstream support ended on 1 March 2025, so it is already in extended support — security fixes only. If you are moving off SQL Server 2016, whose support ended on 15 July 2026, landing on a version already past half its life is worth doing on purpose rather than by habit.
Always On availability groups
The most commonly over-specified project we see, and the most commonly under-tested.
Edition drives the cost, not the engineering. Standard Edition supports Basic Availability Groups: one database per group, one secondary, no readable secondary. Multiple databases that must fail over together, or a secondary you want to read from, means Enterprise Edition — and Enterprise licensing usually exceeds the entire cost of the project. That conversation belongs at the start, not after a design assumes a readable secondary.
A quorum design that survives the failure you are planning for. Two nodes and a file share witness behave differently from three nodes, and multi-site configurations need node weights thought through rather than left at defaults. The question to hold the design against is not "does it fail over" but "which specific failure are we protecting against, and does this survive it".
What availability groups do not replicate. Logins, SQL Agent jobs, linked servers, credentials and certificates live at instance level, not database level. An availability group that fails over perfectly to a secondary with none of the logins is a tested failover and a failed one. Contained availability groups in SQL Server 2022 address part of this; the rest is a checklist.
We fail a cluster over in front of the client before handover, twice. A failover nobody has performed is a hypothesis.
Azure SQL Managed Instance
The closest managed equivalent to a SQL Server instance, and the usual destination when an organisation decides it no longer wants to patch database servers.
What comes across. SQL Agent, cross-database queries, linked servers, Service Broker, CLR — the instance-scoped surface that a lift-and-shift depends on and that Azure SQL Database does not offer. This is why Managed Instance is the realistic target for an existing estate and Azure SQL Database usually is not.
What does not. No filestream or filetable. No cross-instance distributed transactions except through Managed Instance link. Backups are managed by the platform, so an existing backup strategy built on native backups to a share needs rethinking rather than porting.
How the data moves. Azure Database Migration Service with log shipping under it gets most estates to a cutover measured in minutes rather than hours, because the bulk of the data moves while the source is still serving. Managed Instance link extends this further and is worth evaluating for anything where the window is genuinely tight.
The cost conversation is the real one. Managed Instance moves spend from licences and capital to a monthly bill, and the sizing exercise — vCores, service tier, storage — decides whether the move saves money or quietly increases it. That modelling belongs before the decision, not after the migration.
What actually drives the quote
Rarely the database work. Four things move the number:
- Application coupling. One database behind one application is a small project. Nine databases with linked servers between them and two vendors who must both sign off is not.
- Downtime tolerance. A four-hour window and a four-minute window are different architectures, and the difference is most of the cost.
- Environment fidelity. A test environment that resembles production makes the rehearsal meaningful. One that does not means rehearsing on production, which is the thing we are trying to avoid.
- Change control. A weekly CAB and formal test sign-off is not slower to work with, but it has to be planned for rather than discovered.
The failure modes worth planning around
In order of how often we are called in after them:
- No rehearsal. The single strongest predictor of a bad cutover. A dry run against a copy of production is not optional rigour, it is the project.
- A rollback plan that was written but never run. An untested rollback is a paragraph, not a plan. It fails at exactly the moment it is needed.
- Instance-level objects forgotten. Logins, jobs and linked servers, on every migration and every availability group.
- Compatibility level raised at cutover. It bundles an engine change and an optimiser change into one window, so when performance moves nobody knows which one did it.
- No handover. A correct environment nobody internally can operate is a dependency, not a deliverable.
How we engage
Where the scope can be defined, the project is quoted as a single fixed price against written acceptance criteria, with milestone payments. Where it genuinely cannot, we say so and work at $150 an hour rather than quoting a number we would have to revise.
Either way it is delivered by Onsys consultants in Australia — database work is Australian-only, on every engagement. Our SQL Server project services page sets out what each engagement covers, or tell us what you are trying to move and we will scope it on a free call — including when the work is smaller than you expected.