In-Place Upgrade or Side by Side: Choosing Properly

An in-place upgrade changes the existing SQL Server installation, while a side-by-side move prepares another instance. Choose by the testing and recovery paths you need, not by which diagram has fewer boxes.

Separate the Two Decisions

An in-place upgrade retains the existing instance identity while Setup upgrades supported components. A side-by-side migration builds a destination and moves databases and dependencies to it. Both require a supported source-to-target path. Neither route removes the need to test the application.

SELECT
    @@SERVERNAME AS server_name,
    SERVERPROPERTY('ProductVersion') AS version,
    SERVERPROPERTY('Edition') AS edition,
    SERVERPROPERTY('Collation') AS server_collation;

Record the starting configuration before comparing approaches. Include operating system requirements, installed components, and application certification. Preserving the instance name cannot solve an underlying Windows version that does not support the target release.

What In-Place Gives You

Keeping the instance in place can reduce connection changes and avoid running two full environments during the transition. Existing server objects remain part of the installation being upgraded. That convenience is valuable when dependencies are understood and the supported path is straightforward.

The cost is a tighter connection between the upgrade and the live environment. Setup and subsequent recovery occur on the installation you depend on. Downtime includes more than copying binaries. Rehearse the sequence and measure the complete service interruption on representative systems.

An in-place major-version upgrade doesn’t come with a simple database downgrade. Plan recovery through tested backups and a rebuild or alternate environment where required. A virtual machine snapshot needs an application-consistent recovery design and organizational approval. It isn’t automatically a complete SQL Server recovery plan.

What Side by Side Gives You

A separate destination lets you configure, restore, and test before cutover. You can compare application behavior while the original environment still exists. It also creates a natural opportunity to change the operating system or hardware. Those extra changes add variables, so record them clearly.

SELECT
    name, compatibility_level, recovery_model_desc,
    collation_name, state_desc
FROM sys.databases
WHERE database_id > 4
ORDER BY name;

The extra environment has a cost in resources and administration. Synchronizing data before cutover also needs planning. Choose a supported method that fits the database and downtime requirements. A final backup and restore can be adequate for one workload and too slow for another.

Don’t assume a copied database brings logins, jobs, credentials, linked servers, or network configuration. Inventory those separately. Match SQL login SIDs where appropriate and test Windows authentication from the application host. A successful connection from your administrator session doesn’t cover that path.

Put the Cutover Boundary on Paper

Define when writes stop on the old environment and when the destination becomes authoritative. Decide how connections move and how you verify that they moved. Include background jobs and integrations, not only the main application. Two writable copies can create a reconciliation problem quickly.

SELECT
    session_id, login_name, host_name,
    program_name, DB_NAME(database_id) AS database_name
FROM sys.dm_exec_sessions
WHERE is_user_process = 1;

This snapshot helps inspect current connections with suitable permissions. It doesn’t prove no application will reconnect later. Review connection configurations and schedules too. Control access to the old environment through the cutover plan, rather than relying on users to remember a new address.

Test name resolution, listeners or aliases, encryption, and service-account permissions in advance. A side-by-side move changes more than database files. Those surrounding details are frequently the reason a clean restore isn’t yet a working service.

Be Precise About Returning

Before the destination accepts new writes, returning to the old environment can be relatively simple if it remains intact. After new writes occur, the old copy is stale. Repointing connections then loses or splits recent work unless a tested reconciliation path exists.

Backups from a newer SQL Server engine cannot be restored to an older engine. Compatibility level doesn’t remove that boundary. Side by side preserves an old environment, but it doesn’t automatically preserve a current old-version copy of every later transaction.

Write down the last reversible point, the acceptance checks, and the owner of the decision. Include the maximum period you can spend investigating before the fallback becomes unacceptable. Recovery is a procedure with data consequences, not a reassuring arrow on a slide.

Choose the Route You Can Rehearse

Favor the approach that gives the required testing, downtime, and recovery behavior within your constraints. For a tightly controlled small instance, in-place can be reasonable. For a complex estate with uncertain dependencies, a separate destination can provide valuable room to investigate before committing.

Run representative workloads, compare plans, and verify recovery on the chosen route. Record what remains untested. I would rather make the tradeoff explicit than call one method universally safer. The right choice is the one whose failure behavior your team understands and can execute.

An upgrade method is not a recovery guarantee, it is a choice about where you test and where you take risk.

This post was rewritten from scratch in September 2026. The original, published on 2016-11-16, was a short announcement about something that no longer exists. The address is the same, the subject is now something worth keeping.

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