Evaluating a New SQL Server Version in One Week

Most version evaluations either take a quarter or never finish. Evaluating a new SQL Server version fits into one focused week when each day has a single job and Friday ends with evidence your team can act on.

Before Monday, Pick the Questions for Evaluating a New SQL Server Version

A week is short. Do not try to test every feature in the product. Choose the business problem you want to solve and the risks that can block adoption. Write down critical databases, application paths, jobs, drivers, and recovery requirements. Get an application owner to agree on what a useful result looks like.

I will not start an evaluation without the questions written down first. Without them, Friday arrives and the conclusion is that the new version seems nice.

Collect a baseline on the current environment. Record engine build, compatibility levels, server settings, key job outcomes, and measured workload behavior. Keep the query plans for operations that cause pain today. You need a fair comparison later. A new server without a known starting point produces opinions, not a decision.

Book tester time now. An empty test calendar on Friday cannot be fixed by a perfect DBA installation on Monday. Agree on who will run each application check.

Monday: Install and Record the Build

Build a separate Windows test instance from approved media. Apply the selected CU during setup or immediately after, following your tested procedure. Keep the package identity and setup logs. Query the running ProductVersion. Confirm the services, storage, tempdb, memory settings, and network configuration.

Do not let the lab connect to production endpoints by accident. Use test identities and safe network routes. If the release is a preview, review its license terms and keep the box disposable. If it is a supported release, still treat the environment as a controlled test.

Write down every difference from production hardware and configuration. Some are acceptable for feature evaluation. Others limit performance conclusions. A fast lab disk or a tiny memory allocation can distort the result in opposite directions.

SELECT
    SERVERPROPERTY('ProductVersion') AS ProductVersion,
    SERVERPROPERTY('ProductUpdateLevel') AS UpdateLevel,
    SERVERPROPERTY('Edition') AS Edition,
    @@SERVERNAME AS InstanceName;

Tuesday: Restore and Reconnect

Restore a recent production backup, sanitized as your policy requires. Match database compatibility level initially to the planned migration step. Validate database state, users, and permissions. Move required logins and server objects through your approved scripts. Keep external jobs disabled until their endpoints are checked.

Connect the application through its real driver and connection settings. Test authentication, encryption, connection pooling, and the first important transaction. If that fails, fix the connection path before measuring query speed. A SQL query window cannot stand in for the application’s behavior.

Restore tests also reveal migration effort. Note the backup size, restore duration, and post restore work using your actual measurements. These values belong in the eventual cutover estimate. Do not borrow figures from another environment.

After the restores, capture the state you are evaluating, so Thursday’s comparisons start from facts rather than memory.

SELECT
    d.name,
    d.compatibility_level,
    d.is_query_store_on,
    d.recovery_model_desc
FROM sys.databases AS d
WHERE d.database_id > 4
ORDER BY d.name;

Wednesday: Run the Workload

Run the critical application flows, Agent jobs, ETL, reports, and maintenance tasks. Use representative data and parameters. Capture errors, output, duration, CPU, logical reads, and actual plans for selected queries. Use the same measurement approach you used on the source.

Include concurrency where it matters. One query in isolation does not reveal blocking or memory pressure from several users. A focused replay of known busy periods can expose a problem that a feature demonstration misses. Record the workload source and its limits.

Check backup and restore on the new instance. Check monitoring and alert delivery. If availability is a requirement, test the topology or state clearly that this week’s lab did not cover it. Evidence is strongest when its boundaries are visible.

Thursday: Compare and Investigate

Compare the new results with the baseline. Separate correctness, operations, and performance. A query can be faster while a nightly job fails. A database can restore cleanly while a vendor tool rejects the new version. Do not roll those facts into one green label.

I spend more time on Thursday than on any other day of that week. The differences are where the decision lives.

What would make you say no? If nobody can answer that by Thursday, the evaluation has turned into a demo.

Investigate changed plans with statistics, compatibility level, parameters, and settings in view. Check the release notes for known issues. If a feature you need is deprecated or removed, write the replacement work down. Time spent on a real blocker is more valuable than touring another feature.

Run one focused retest after each fix. Record what changed. A change to compatibility level or an index can alter results, so keep the variables visible. If the team cannot resolve a blocker by Friday, that is a valid evaluation result.

Friday: Finish Evaluating the New SQL Server Version With a Decision

Write a short report with the exact tested build, restored data date, application checks, job outcomes, performance comparisons, defects, and migration work. Include the risk of waiting as well as the risk of moving. Recommend a next step: proceed to a broader pilot, fix a blocker, or defer with a review date.

Ask the application owner and operations owner to review the result. Their sign off should refer to specific checks, not a vague feeling. If the lab differs materially from production, name the additional test needed before a go live decision.

Keep scripts and logs in a controlled location. Destroy copied sensitive data when the evaluation ends. A good week leaves a repeatable test kit even when the answer is “not yet.”

Protect the Scope of Evaluating a New SQL Server Version

Evaluating a new SQL Server version in one week is a gate, not a production migration. It should identify major blockers and estimate the work needed next. It cannot prove every peak season workload, every disaster recovery event, or every vendor support path. List those as follow up tests rather than hiding them.

The tight schedule works because each day has one deliverable. Monday gives you a known build. Tuesday gives you restored data and a working connection. Wednesday gives you workload evidence. Thursday explains differences. Friday gives the team a decision.

I have seen evaluations stall when everyone spends the week arguing about which server to test. Set the build and questions in advance. Then use the week to learn something you can act on.

Related reading on this blog: How to Learn a New SQL Server Release Quickly and How to Evaluate a New Database Without Fooling Yourself.

A week of evaluation is not a feature tour, it is a short path from a known build to a useful decision.

Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.