Back to Insights

Technical Insight

SQL Server Upgrade Readiness Checklist for Business Applications

SQL Server upgrades are business projects, not only infrastructure tasks. The application, database compatibility level, jobs, logins, reports, integrations, backups, and user acceptance process all need to be reviewed before production cutover.

SQL ServerMigrationBackupsCompatibility

01

Start with the application dependency map

The first mistake in many upgrade projects is treating the database server as an isolated machine. Business applications may depend on SQL Agent jobs, service accounts, linked servers, scheduled exports, file paths, reporting services, ODBC drivers, printer processes, and vendor-specific components.

Before selecting the target SQL Server version, document every application and integration that touches the instance. This prevents a situation where the database engine is upgraded successfully but a critical workflow stops because a job, login, or driver was missed.

Checklist

  • βœ“List every database and its owner application.
  • βœ“Record database sizes, recovery models, compatibility levels, and file locations.
  • βœ“Inventory SQL Agent jobs, maintenance plans, operators, alerts, and schedules.
  • βœ“Export logins, server roles, credentials, proxies, linked servers, and endpoints.
  • βœ“Identify reporting tools, application connection strings, and external integrations.

02

Validate backups before changing anything

A backup that has never been restored is an assumption, not a recovery plan. Before any upgrade, take current full backups and validate that restore procedures work on a test environment. This is especially important for large databases, compressed backups, encrypted backups, and systems with tight downtime windows.

Also review transaction log size, recovery model, backup retention, available disk space, and time required to restore. These numbers influence the real cutover plan.

  • β€’Run full backups close to the migration window.
  • β€’Restore to a non-production server and run DBCC checks.
  • β€’Confirm application can connect to restored databases.
  • β€’Record restore duration and required storage.
  • β€’Keep rollback backups isolated from the target change process.

03

Compatibility and performance testing

Compatibility level, cardinality estimator behavior, deprecated features, reserved words, driver versions, and query plan changes can affect the application. A test migration should include real business workflows, not just database online status.

Create a performance baseline before migration. Capture query duration, CPU, waits, job duration, report generation time, database file growth, and application response times for important workflows. After migration, compare those baselines instead of relying on subjective user feedback only.

Checklist

  • βœ“Run vendor compatibility checks and SQL Server upgrade assessment tools where applicable.
  • βœ“Test representative application screens and reports.
  • βœ“Review deprecated features and breaking behavior changes.
  • βœ“Capture pre-upgrade and post-upgrade performance baselines.
  • βœ“Keep compatibility level changes controlled and reversible.

04

Cutover and rollback planning

A credible cutover plan names each step, owner, estimated duration, validation point, and rollback decision point. It should also define who communicates with users, when the system is frozen, when final backups are taken, and how success is declared.

Rollback is not a paragraph at the end of a document. It is a tested path back to service if validation fails. For some systems, rollback means restoring databases to the old server; for others, it may require DNS, connection strings, services, jobs, and application configuration changes.

  • β€’Freeze data changes and communicate downtime.
  • β€’Take final backups and verify completion.
  • β€’Restore/migrate databases to the target instance.
  • β€’Apply logins, jobs, linked servers, and configuration.
  • β€’Run application smoke tests and business validation.
  • β€’Hold a rollback decision before releasing the system to all users.

Related reading

Continue exploring