A SQL Server migration moves your databases to new hardware, a new version, or the cloud. An upgrade moves you to a newer SQL Server release. Both are routine when planned, and painful when rushed. The work is the same shape every time: know what you have, test the move on a copy, then cut over in a window you control. The surprises live in the testing you skip.
Most migration disasters are not technical. They are a cutover with no rollback plan. We always have one.
Why upgrade at all
- End of support. Old SQL Server versions stop getting security fixes. That is a compliance and risk problem, not just a missing feature.
- Performance. Newer versions plan queries better and use modern hardware properly.
- Licensing. An upgrade is the moment to right-size editions and stop overpaying.
On-prem or Azure?
Three real options when you move to Azure, and they are not interchangeable.
- SQL Server on an Azure VM. The most like what you have now. You still run the OS and patching. Easiest lift.
- Azure SQL Managed Instance. Near-full SQL Server, managed for you. The usual landing spot for existing apps.
- Azure SQL Database. Single databases, fully managed. Great for new builds, more work to retro-fit old apps.
How we run a migration
- We inventory every database, version, dependency and job. The list is always longer than people expect.
- We test the move on a copy. Compatibility, performance, the overnight jobs. We find the breakage here, not on cutover night.
- We plan the cutover with a rollback. A window, a checklist, and a way back if something fails.
- We cut over, watch it, and stay on it until it is quiet.
Frequently asked questions
How long does a SQL Server migration take?
A single database can be days. A full estate with old apps and overnight jobs is weeks, most of it testing. We give you a real timeline after the inventory, not a guess.
Will my application still work after an upgrade?
Usually, and we prove it on a copy before cutover. Compatibility level lets us upgrade the engine while keeping the old query behaviour, then move forward when you are ready.
Should I move to Azure or stay on-prem?
It depends on your workload, your team, and your costs. We model both, including licensing and Azure Hybrid Benefit, and give you the numbers. Sometimes the answer is to stay.
Start with the inventory
Planning a move, or stuck on an old version? The first step is the same. Inventory every database, version, dependency and job. The migration plan and the timeline come off that list, not off what anyone remembers.
Tell us what is going on. A senior DBA reads every message and points you at the right next step, even when that is not us. A free read-only check will tell you whether this one is sitting in your estate.
Get pointed in the right direction