A new preview build always gets somebody excited, and that is fine as long as it stays in the lab. Preview builds let you study future SQL Server behavior early, inside a controlled evaluation with a license review, disposable data and a clear end date.
Read the Terms for That Build
A preview download comes with its own license terms. Read the terms attached to the exact build before installation. Check permitted users, allowed environments, expiration, data handling, and redistribution. Terms can differ between programs and releases. A colleague’s memory of an older CTP is not authority for the one in front of you.
Write down the source package, terms version, and evaluation owner. Keep those records with the test plan. If a vendor application is involved, check its support statement too. Microsoft preview terms and vendor support are separate questions. A test can be permitted by one agreement while the application vendor declines to support it.
Do not assume a preview is licensed for live business processing. The safe pattern is a lab instance with test data and no production dependency. If the license says something different, follow the actual text. The point is to know the boundary before the first restore.
Expect Limited Support for Preview Builds
Preview builds exist to gather feedback and expose issues before general release. It does not carry the same support expectation as a stable production build. Read the program’s support channels and limitations. File a clear bug report when you find a defect. Keep a reproduction script, build number, error text, and expected behavior.
I have been asked more than once to rescue something that went into production on a preview build because it was only temporary. Temporary is a surprisingly durable state in IT.
Do not promise an application owner that a preview defect will be fixed on your schedule. You have no production service level to lean on. For a business deadline, use a supported release and a supported feature set. A preview can inform your design, but it should not become a hidden critical dependency.
The preview also needs a clock. Record its expiration date or evaluation end date if the terms include one. Set a reminder to retire the environment. A forgotten lab machine can turn into a brittle service simply because someone found it useful.
Do Not Bet on an Upgrade Path From Preview Builds
There is no universal guarantee that a preview database or instance can be upgraded in place to the final product. Setup behavior, database format, features, and compatibility rules can change. Plan to rebuild the instance and restore from a supported source. Keep scripts for schema and configuration so the evaluation can be repeated.
Never make the preview copy the only copy of business data. Keep the original backup in the supported environment. A database moved forward to a newer engine cannot simply be attached to an older engine. This is especially important when the preview has performed internal database upgrades.
If your test creates useful work, export the design decisions and scripts, not a promise that the preview instance will live forever. A good evaluation leaves behind a reproducible result and a clean disposal path.
Build an Isolated Lab
Use a separate virtual machine or isolated instance with a clear name and restricted network access. Avoid shared hosts that also carry production SQL Server services. Preview setup can install shared components and change machine state. A disposable machine keeps those changes inside the test boundary.
Create the VM from an approved operating system image. Patch the host, set a strong administrative boundary, and capture a snapshot before installation. Use a copy of data that has been sanitized according to policy. Remove credentials, linked server secrets, and live connection strings. A lab should not send email to customers or run production integrations by accident.
Document the build, image, and network rules. Another DBA should be able to recreate the test. When the preview ends, delete the VM and its copied data through the normal disposal process.
Before the first test, confirm the lab really is running the preview and not a build left over from the last experiment.
SELECT
@@SERVERNAME AS ServerName,
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductLevel') AS ProductLevel,
SERVERPROPERTY('Edition') AS Edition;Test One Question at a Time
Pick specific questions. Does a new feature improve the query pattern you care about? Does a syntax change affect your deployment scripts? Does the feature behave correctly under your application’s workload? Define the check before running it. A feature tour is fun, but it rarely produces a usable decision.
I keep a preview lab so small that nobody is tempted to put real work on it. The moment a preview server gets a friendly name, somebody finds a use for it.
Which single question would change your decision? Write it down before you install anything.
Run baseline tests on your current supported release. Then run the same workload in the preview, with known differences documented. Capture plans, errors, output, and measured timings from both. Do not publish a made up performance claim based on a screenshot. Use queries and logs that another engineer can repeat.
Keep feedback focused. A bug report should include the preview build number, minimal steps, and observed output. The product team can act on a small reproduction faster than on “it seems slower.”
SELECT
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('ProductLevel') AS ProductLevel,
SERVERPROPERTY('Edition') AS Edition,
@@SERVERNAME AS ConnectedInstance;Protect Production Boundaries From Preview Builds
A preview should not join your normal failover topology. It should not become a backup destination for the only good copy of a database. Avoid connecting it to production jobs, monitoring actions, or deployment pipelines that assume a supported release. Label the VM and the database clearly as evaluation assets.
Use a separate test identity with least privilege. Do not copy a production service account password into a lab. If the application needs external services, use test endpoints. Check scheduled jobs after restoring msdb content or migrating job scripts. Disable anything that could contact live systems.
Audit the network route before a test involving real application traffic. An accidental connection to production can invalidate results and create side effects. A safe evaluation gives you room to break the software without breaking Tuesday for everyone else.
Finish With a Decision
At the end, write what the team learned. Name the exact preview build and terms reviewed. List features tested, scripts used, results observed, defects found, and unknowns left for the final release. Separate a promising feature from a production commitment. A preview result is a lead for later validation.
I give every preview lab an end date on the day it is built, and I put that date in a calendar somebody else can see.
Decide whether to test again at release candidate or general availability. Put that task on a calendar with an owner. If the feature is not useful, say so. If it is useful, define what evidence the supported release must provide before adoption.
Finally, retire the lab. Remove copied data and credentials. Keep the notes and reproduction scripts. The best preview test is one you can repeat on a supported build when the decision becomes real.
Related reading on this blog: What a Preview Build Is For, and What It Is Not and Building a SQL Server Home Lab That Costs Nothing.
A preview is not a shortcut to production, it is a safe place to learn before production.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
