The support deadline is close, and your application still runs on an old SQL Server version. Start with what you own, then give the move a target and a date.
Count Every Dependency
The first job is finding every instance that belongs to the application. Check named instances, availability replicas, reporting copies, test systems, and machines hidden behind an alias. Ask the backup and monitoring teams for their lists. Their gaps are useful. I find the forgotten instance by comparing lists, not by trusting one spreadsheet.
List the databases, Agent jobs, linked servers, logins, credentials, SSIS packages, reports, and application connection strings. A database restore does not carry all of them. Keep the business owner and technical owner beside each item. If ownership is unknown, make that a task with a due date. Silence is not an owner.
Which process would fail if this machine vanished tonight? Ask that before choosing the migration method. The answer tells you where to test first. It also reveals whether the old instance serves more than one application.
Capture the State of the Old SQL Server Version
Record the full engine build, edition, operating system, database compatibility levels, and high availability layout. Save the capture date. An inventory from last year is a story about last year. I run the version query directly on each instance before I trust a migration plan.
Collect backup history and prove a restore. Record recovery point and downtime requirements with the application owner. A plan that needs four hours of outage cannot be approved against a thirty minute business limit. Use measured restore tests to set a credible window. Do not fill the schedule with borrowed numbers.
Keep server configuration and important trace flags in the record. They influence behavior after the move. The goal is not to copy every old choice. It is to know which differences you will test on the target.
SELECT
@@SERVERNAME AS ConnectedInstance,
SERVERPROPERTY('ProductVersion') AS ProductVersion,
SERVERPROPERTY('Edition') AS Edition,
SERVERPROPERTY('ProductUpdateLevel') AS UpdateLevel;Choose a Supported Landing Place
Pick a supported SQL Server release and an approved update level. Confirm the operating system, drivers, backup tools, and vendor software work with that combination. A new engine on an unsupported host simply moves the problem sideways. The target also needs a support horizon long enough to justify the project.
Compare an in place upgrade with a side by side migration. An in place upgrade changes the existing instance and has a narrower return path. A side by side move gives you a separate target for repeated restores and application tests. It also needs a deliberate data cutover. Let recovery requirements decide, not whichever installer looks shorter.
Do you have a vendor application? Get its certification statement before you book the production window. A calendar does not negotiate with old drivers.
Check Compatibility in Layers
Database compatibility level is one layer. The new engine can run a restored database at an older supported level, while engine behavior and security defaults still change. Test both the initial landing state and any later compatibility level change. Do not bundle every change into the same late night window.
Run a representative application workload on restored data. Check logins, reports, jobs, imports, and external integrations. Compare query plans and measured performance for important paths. Search the target release documentation for deprecated or removed features you use. A feature warning found before cutover is a project task. Found during cutover, it becomes everyone’s evening.
Keep the test results attached to the exact target build. A passing test on another CU does not certify this one.
SELECT
name,
compatibility_level,
recovery_model_desc,
state_desc
FROM sys.databases
WHERE database_id > 4
ORDER BY name;Retire the Old SQL Server Version Before Support Ends
Set a retirement date before the old SQL Server version leaves support. Work backward through production cutover, user acceptance, performance testing, target build, and discovery. Give each milestone an owner. Reserve time to fix findings. If testing ends on the same day as cutover, the schedule has no room for truth.
Include a fallback route. After a database moves to a newer major version, you cannot attach its new files to the old engine. A reverse route needs a compatible backup, a logical data return plan, or a decision about acceptable data loss. Agree on that with the business before the first write reaches the target.
If the schedule misses the deadline, document temporary controls and eligible support options. That bridge needs an expiry date. It is not the migration plan.
Rehearse the Cutover
Restore a fresh copy to the target. Script logins and jobs. Test the application against the new connection endpoint. Rehearse stopping writes, moving the last changes, switching the alias or listener, and validating the first business transaction. Write down the actual elapsed steps from your rehearsal.
Watch for work outside SQL Server Agent. Windows scheduled tasks and application queues can write to the old server after the main application switches. Include those owners in the runbook. I have seen a cutover look clean until a quiet integration wakes up the next morning.
Keep the old source protected during the agreed fallback period. Do not let users keep writing to both places. Two active sources turn a migration into a reconciliation project.
Close the Door on the Old SQL Server Version
After cutover, check application traffic, backups, monitoring, jobs, and support ownership on the target. Keep a list of old endpoint connections and investigate each one. The migration is not complete when the new login succeeds. It is complete when the service runs and the old path is no longer needed.
Preserve required backups and audit records under your retention rules. Then disable and retire the instance on the old SQL Server version through change control. Update the inventory with the retirement date. Remove the temporary network and credential exceptions left from testing.
The support deadline is a useful forcing function. Use it to give the move a real schedule, not a last minute scramble.
Related reading on this blog: Microsoft Official Support End Dates for Different Versions and How Old Version of SQL Server Running on Server? Interview Question of the Week #183.
An old version is not a calendar problem, it is a dependency problem with a date.
Published by Pinal Dave on SQLAuthority. More of my work at pinaldave.com.
