SQL Server upgrades and migrations
The successful migration is the one users barely notice
Moving to a new SQL Server version, new servers, new hosting or Azure is mostly planning, testing and rehearsal. The cutover itself should be the uneventful part.
What we move
Upgrades, moves and consolidation
SQL Server upgrades, server moves and cloud migrations, with the data verified at every stage.
- Version upgradesFrom out-of-support versions to a current release, in place or side by side.
- Server replacementNew hardware or virtual machines, new operating system, same databases.
- ConsolidationSeveral small instances onto fewer, with the licensing and workload effects understood.
- Hosted infrastructureMoves into or between data centres and hosting providers.
- Azure SQL DatabaseFor applications that suit a managed, database-level service and don’t rely on instance features.
- Azure SQL Managed InstanceNear-complete instance compatibility, including SQL Agent and cross-database queries, without managing the operating system.
- SQL Server on Azure VMsFull control and compatibility when the application needs everything an on-premises instance offers.
How we approach it
Assess, plan, test, rehearse, cut over
Assessment
An inventory of instances, databases, sizes, logins, SQL Agent jobs, linked servers, SSIS packages, reports and the applications that connect, and the features each one relies on.
Planning
The target platform and version, the migration method for each database (backup and restore, log shipping, replication or Azure Database Migration Service) and the downtime each would need.
Compatibility testing
Deprecated and discontinued features, behaviour changes under a newer compatibility level, and a comparison of query performance before and after, using Query Store where available.
Rehearsal
A timed trial run to a test environment, so the real cutover follows a script that has already worked.
Cutover
A planned window with checkpoints, data verification, row counts and application sign-off before users are let back in.
Rollback
A defined point up to which we can return to the old environment, and the decision criteria for doing so, agreed in advance.
Where migrations usually go wrong
- Logins moved without their original SIDs, leaving database users orphaned
- SQL Agent jobs, linked servers, credentials and certificates left behind
- Queries that regress under the new cardinality estimator once the compatibility level is raised
- Hard-coded server names in connection strings, reports and integration packages
- Collation differences between old and new instances
- No agreed point at which to roll back, so a bad cutover drags on
Before you commit
If you’re not yet sure where SQL Server should go, or whether an upgrade is safe for your applications, start with a migration assessment. It sets out the options, the risks, the downtime involved and the work required, so the decision is made with the facts in front of you.
Ask for a fixed-price assessment. We’ll give you a fixed price after a short conversation.
Next step
Planning an upgrade or a move?
Tell us the current versions, where SQL Server needs to go and any deadline you’re working to.