SQL Server Migration to Windows VPS: 2025 Upgrade & Cutover Guide

In short

A SQL Server migration to a Windows VPS should be treated as a database-and-application cutover, not a file copy. The safest pattern for most small and mid-sized Windows workloads is to build the target server side by side, assess compatibility, restore a test copy, migrate server-level dependencies such as logins and jobs, validate the application, then perform a controlled final cutover with rollback still available.

Raff Technologies provides Windows VM infrastructure that can be used as the destination for supported SQL Server workloads. The database owner, MSP, or application team still needs to confirm SQL Server edition and licensing, application compatibility, database recovery requirements, migration method, backup integrity, network access, and post-migration operations.

In 2026, there is one important update to older SQL migration advice: Microsoft now documents the SQL Server migration component in SQL Server Management Studio (SSMS) as a primary workflow for SQL Server-to-SQL Server assessment and migration. For SQL Server 2025 targets, it can assess upgrade compatibility and use a backup-copy-restore workflow to move databases and logins. Manual backup/restore remains a strong and transparent option when you want full control of the migration sequence.

Quick decision: which SQL Server migration method should you use?

For most Raff Windows VM migrations, side-by-side build + compatibility assessment + test restore + final cutover is the cleanest model.

SQL Server migration is more than moving .mdf and .ldf files

A production SQL Server instance can include far more than the user database itself.

A migration is successful only when the application and its operational dependencies work on the destination.

What changed for SQL Server migration in 2026?

Microsoft's current guidance for upgrading SQL Server databases to newer versions centers on the migration component in modern SQL Server Management Studio.

The migration component can:

• assess compatibility issues before an upgrade;
• identify breaking or behavior changes;
• review deprecated features;
• move databases with a backup-copy-restore workflow;
• transfer logins during the migration workflow;
• support side-by-side SQL Server migration scenarios.

For this workflow, Microsoft documents SSMS 21 or later as a prerequisite.

That matters because older migration checklists often point first to retired or older assessment patterns. In 2026, use Microsoft's current SSMS migration workflow when it matches the project, and keep manual backup/restore as the transparent fallback or preferred DBA-controlled method.

SQL Server 2025: check the source version before you upgrade

SQL Server 2025 is Microsoft's current major SQL Server release. Microsoft documents supported in-place upgrade paths from:

• SQL Server 2014 SP3 or later;
• SQL Server 2016 SP3 or later;
• SQL Server 2017;
• SQL Server 2019;
• SQL Server 2022.

Older SQL Server versions may still be migrated to SQL Server 2025 using a side-by-side migration path rather than a direct in-place upgrade.

For backup/restore specifically, Microsoft documents that backups from SQL Server 2008 and later can be restored to SQL Server 2025 when the database compatibility conditions are met. Backup compatibility is forward-only: a backup created by a newer SQL Server version cannot be restored to an older SQL Server version.

The practical rule is:

Old SQL Server -> newer SQL Server
Usually possible after compatibility checks

Newer SQL Server backup -> older SQL Server
Not supported as a normal restore path

Do not pick SQL Server 2025 only because it is the newest release. The target version must also be supported by the application vendor, drivers, reporting tools, integrations, and any third-party extensions.

Step 1 — Inventory the source SQL Server instance

Before choosing a migration tool, document what exists.

This inventory should answer one question: what must exist on the destination for production to behave the same way?

Step 2 — Decide whether this is migration, upgrade, or both

These projects are related but not identical.

If the current application is business-critical, changing the SQL Server major version during the same cutover can add unnecessary risk. Sometimes the safer sequence is:

1. migrate to the new Windows VPS on a supported SQL version;
2. stabilize the workload;
3. upgrade SQL Server in a separate tested change.

If the source SQL release is near end of support or the application requires a newer version, combining the work may still make sense—but test it as an upgrade project, not just a server move.

Step 3 — Run a compatibility assessment before a major-version upgrade

For a move to a newer SQL Server major version, run the current SSMS migration assessment before cutover.

Microsoft's migration component checks areas such as:

• breaking changes;
• behavior changes;
• deprecated features;
• target compatibility concerns;
• affected database objects.

Treat assessment findings as migration blockers until reviewed.

Also test the actual application. A compatibility assessment can identify SQL-level issues, but it cannot prove that every third-party application workflow behaves correctly.

For older business applications, validate:

• ODBC/OLE DB drivers;
• .NET SQL client behavior;
• stored procedures;
• SQL authentication;
• deprecated data types or syntax;
• reporting tools;
• vendor-specific database checks;
• database compatibility-level requirements.

Step 4 — Validate database integrity before you migrate

Do not discover source corruption during cutover.

Before migration:

• confirm recent backups complete successfully;
• perform a test restore;
• review database health;
• run appropriate integrity checks such as DBCC CHECKDB according to your DBA process;
• confirm enough free disk space for backup, copy, restore, and database growth;
• resolve any suspect or recovery-pending databases before migration.

Microsoft's current SSMS migration guidance specifically recommends validating the source databases are in a known good state before migration.

A successful backup file is not enough. A successful restore test is much stronger evidence.

Step 5 — Choose backup/restore or the SSMS migration component

Option A: manual backup and restore

This is usually the easiest migration method to understand and audit.

Typical flow:

Source SQL Server
-> full backup
-> copy backup to destination
-> restore on Windows VPS
-> migrate server-level dependencies
-> point test application to destination
-> validate
-> final backup/log sequence
-> production cutover

Use it when you want direct control over backup files, restore options, file placement, and cutover timing.

Option B: SQL Server migration component in SSMS

Microsoft's current migration component can assess and physically migrate SQL Server databases using backup-copy-restore. It can also transfer logins as part of the workflow.

This is useful when:

• you are moving SQL Server to a newer SQL Server instance;
• you want Microsoft's current integrated assessment workflow;
• you want assistance transferring databases and logins;
• both source and destination can use the required backup/copy shares.

It still does not eliminate the need to inventory SQL Agent jobs, linked servers, application settings, certificates, permissions, or rollback.

Step 6 — Protect TDE certificates and encryption keys

Transparent Data Encryption changes the migration plan.

If a database is protected by TDE, the destination needs the appropriate certificate or asymmetric key material before the encrypted database backup can be restored or migrated successfully.

Before cutover:

1. identify TDE-protected databases;
2. back up the certificate and private key securely;
3. protect the password separately;
4. import the required key material on the target instance;
5. test the restore before production migration.

Do not leave certificate/key transfer until the cutover window.

Step 7 — Plan the recovery model and final cutover sequence

Recovery model determines how much of the transaction log can be used during migration.

Define:

• RPO: maximum acceptable data loss;
• RTO: maximum acceptable downtime.

For a small database with a one-hour maintenance window, a final full backup may be enough.

For a larger or busy database, use a staged restore model:

Full backup -> restore WITH NORECOVERY
Differential backup -> restore WITH NORECOVERY
Transaction log backups -> restore WITH NORECOVERY
Final tail/log backup -> restore
Recover database
Cut over application

The exact sequence depends on recovery model and migration design. Test it before the real maintenance window.

Step 8 — Preserve logins and prevent orphaned users

Database users and SQL Server logins are different objects.

After a database restore, a database user can exist while its matching server login is missing or has a different SID. This creates an orphaned-user problem.

Review:

The SSMS migration component can help move logins, but verify the final mappings rather than assuming every authentication dependency moved correctly.

Step 9 — Migrate SQL Agent jobs and server-level dependencies

A restored database can look healthy while scheduled business processes are silently broken.

Check:

• SQL Agent jobs;
• job schedules;
• job owners;
• operators and alerts;
• maintenance plans;
• Database Mail;
• linked servers;
• credentials and proxies;
• SSIS packages;
• server-level triggers;
• custom error messages;
• backup jobs;
• import/export scripts;
• file-system paths;
• Windows Scheduled Tasks outside SQL Server.

Microsoft's migration guidance specifically notes preserving automated tasks such as SQL Agent jobs. Treat them as part of the migration, not cleanup after the migration.

Step 10 — Design the destination storage before restoring

Do not blindly recreate source drive letters if the target design should change.

Plan separately for:

• SQL data files;
• transaction log files;
• TempDB;
• backup staging;
• application files;
• exports and imports;
• free-space reserve.

Consider the peak migration requirement, not only the final database size. During migration you may temporarily hold:

Live database
+ backup file
+ restored database files
+ log growth
+ temporary migration copies

A nearly full disk can turn a simple cutover into an outage.

Step 11 — Keep application traffic private where practical

If the application and SQL Server run on separate Windows VMs, use private networking between them when the architecture supports it.

Do not expose SQL Server publicly simply because the application needs remote users. Remote users should normally reach the application tier, not an open database port.

Step 12 — Restore a test copy before production cutover

Never make the first restore the production restore.

A useful test sequence is:

1. build the Windows VPS;
2. install the chosen SQL Server version and current updates;
3. configure storage and service accounts;
4. restore a recent production backup to a test database or isolated target;
5. migrate logins and required server objects;
6. connect a test copy of the application;
7. run business workflow tests;
8. measure performance;
9. test backups on the destination;
10. test a restore from the destination backup chain.

As of September 2026, Microsoft's SQL Server update history shows SQL Server 2025 has continued receiving cumulative updates. Build the destination using a supported, patched level rather than assuming RTM media is current.

Step 13 — Test the application, not just SQL Server Management Studio

A successful query in SSMS does not prove the migration.

Test with real application workflows:

For ERP and inventory workloads, test the operational processes too: reporting, label printing, exports, stock updates, and scheduled integrations.

Step 14 — Plan connection-string cutover

Identify every place that contains the old SQL Server name, IP, or instance.

Common locations include:

• web.config;
• appsettings.json;
• environment variables;
• Windows service configuration;
• ODBC DSNs;
• registry entries;
• scheduled scripts;
• IIS applications;
• reporting tools;
• desktop app configuration;
• linked applications;
• ETL jobs.

Decide whether cutover changes:

• server hostname;
• DNS alias;
• instance name;
• port;
• authentication method;
• certificate requirements.

Document the rollback value for every change.

Step 15 — Run the final production cutover

A typical controlled cutover looks like this:

1. confirm source health and latest successful backups;
2. notify users of the maintenance window;
3. stop application writes;
4. take the final planned full/differential/log backup sequence;
5. copy the remaining backup files;
6. restore the final sequence on the destination;
7. recover the database;
8. verify database state and integrity checks required by your process;
9. confirm logins, jobs, permissions, linked servers, and certificates;
10. update connection strings, DNS aliases, or application configuration;
11. start the application;
12. run smoke tests and business validation;
13. confirm destination backups and monitoring are active;
14. keep the old SQL Server available for rollback until acceptance criteria are met.

Do not decommission the source server during the same moment you declare the migration successful.

Step 16 — Define rollback before the maintenance window

Rollback is not “restore something if it fails.” It is a written decision path.

Define:

Rollback becomes much harder after users start writing independently to the new database. Control when production writes begin.

Step 17 — Validate backups after the migration

The destination should have a recovery plan before the source is retired.

Do not treat a VM snapshot as a replacement for a SQL Server-aware backup strategy.

Common SQL Server migration mistakes in 2026

Using an old migration-tool checklist

Microsoft's current SQL Server-to-SQL Server workflow now includes the migration component in modern SSMS. Revalidate tooling before following an older guide.

Changing server and SQL major version without application testing

A database can restore successfully while the application fails because of drivers, compatibility behavior, or vendor restrictions.

Forgetting TDE certificates

Encrypted databases require the correct key material on the destination.

Restoring databases but not instance-level dependencies

Logins, SQL Agent jobs, linked servers, Database Mail, credentials, proxies, and server configuration can be essential.

Forgetting that backups are forward-only

A backup taken on a newer SQL Server cannot normally be restored to an older major version. Plan rollback before the target becomes the only writable copy.

Letting SQL Server use all available RAM

If the Windows VPS also runs an application or RDS sessions, configure SQL Server memory deliberately. Use SQL Server Max Server Memory.

Exposing SQL Server to the public internet

Use private networking or tightly restricted management paths instead of broad public database access.

Declaring success before backup verification

Migration is not complete until destination backups run and at least one recovery path is validated.

How Raff fits SQL Server migration

Raff can provide the Windows VM infrastructure for supported SQL Server workloads used by business applications, ERP/inventory systems, IIS/.NET applications, Microsoft Access back ends, accounting tools, and MSP-managed client environments.

A practical architecture can start with one Windows VM for a small workload. As demand grows, the application/RDS tier and SQL Server tier can be separated over private networking.

Raff provides the infrastructure layer; the migration owner still needs to handle:

• SQL Server installation and edition choice;
• application compatibility;
• SQL licensing requirements;
• database migration method;
• logins and server objects;
• backups and restore testing;
• application cutover;
• monitoring and database administration.

For SQL-backed ERP and inventory workloads, pair this guide with ERP Hosting on Windows VPS and Inventory & Warehouse Software on Windows VPS.

Final SQL Server migration checklist

Before production cutover, confirm:

If one of these production-critical items is unknown, resolve it before the final cutover.

Validation scope

This September 2026 refresh revalidated the article against Microsoft's current SQL Server 2025 and SSMS migration documentation. It updates the workflow to include the SQL Server migration component in SSMS, SQL Server 2025 supported upgrade paths, forward-only backup compatibility, TDE migration prerequisites, and current patching expectations.

The four existing migration diagrams were preserved. This refresh does not claim a new end-to-end SQL Server migration benchmark or a newly completed production migration on Raff. Exact application compatibility, SQL licensing, downtime, and performance must be validated for the customer's workload.

What's next

• hosted SQL Server — choose the Windows VM after sizing SQL Server and the application.
• Raff Pricing — review current Windows VM pricing.
• Windows Server Migration Checklist — coordinate the broader server cutover.
• Local Server to Cloud Windows VPS Migration — plan a full office-server move.
• File Server Migration to Windows VPS — migrate shares that live beside SQL Server.
• SQL Server Max Server Memory — configure SQL memory after migration.
• SQL Server Backup Strategy — design ongoing database recovery.
• ERP Hosting on Windows VPS — plan a SQL-backed ERP workload.
• Windows Server Hardening Checklist — secure the destination server.

Sources

• Microsoft Learn — SQL Server migration documentation: https://learn.microsoft.com/en-us/sql/sql-server/migrate/
• Microsoft Learn — Upgrade SQL Server to the latest version: https://learn.microsoft.com/en-us/sql/sql-server/migrate/guides/sql-server-to-sql-server-upgrade-guide
• Microsoft Learn — Upgrade SQL Server using the migration component in SSMS: https://learn.microsoft.com/en-us/ssms/migrate-sql-server-component
• Microsoft Learn — Supported version and edition upgrades for SQL Server 2025: https://learn.microsoft.com/en-us/sql/database-engine/install-windows/supported-version-and-edition-upgrades-2025
• Microsoft Learn — SQL Server 2025 release notes: https://learn.microsoft.com/en-us/sql/sql-server/sql-server-2025-release-notes
• Microsoft Learn — Latest SQL Server updates and version history: https://learn.microsoft.com/en-us/troubleshoot/sql/releases/download-and-install-latest-updates
• Microsoft Learn — Back up and restore SQL Server databases: https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/back-up-and-restore-of-sql-server-databases
• Microsoft Learn — Recovery models: https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/recovery-models-sql-server
• Microsoft Learn — Transfer logins and passwords between SQL Server instances: https://learn.microsoft.com/en-us/troubleshoot/sql/database-engine/security/transfer-logins-passwords-between-instances
• Sources revalidated: 2026-09-11