Before you start
Prepare a complete, dated backup and keep an independent copy. Stop writes or use an application-consistent backup method; copying a live directory is not proof of database consistency. Test restoration in an isolated destination. Keep the original untouched until validation.
Record Windows edition and licence conditions
Record Windows Server version, build, edition and activation/licensing arrangement, application dependencies and architecture. A provider-supplied Windows or application licence is not automatically transferable. Confirm destination licensing before ordering; this guide neither changes licences nor converts evaluation media.
Record the exact versions, startup settings, storage actually used and external dependencies. Inventory accounts, permissions, scheduled tasks, databases, licences, certificates and services outside the file directory. Check what the old provider permits you to export before cancelling anything.
- Windows Server version / edition / build
- licensing arrangement
- application requirements
Read OS details
Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumberNo real migration, backup verification or compatibility test has been performed by this page. Retain the source and a tested recovery path. There is no guarantee of zero downtime, unchanged IP, transferable licences or loss-free restoration.
Choose an application or supported backup restore
A clean application-level rebuild often separates data from provider-specific drivers and networking. Restoring a Windows system image requires compatible boot mode, storage drivers, hypervisor support and a tested recovery process. Do not assume a VHD/VHDX or snapshot will boot unchanged on any KVM platform. Domain controllers, clusters and encrypted/TPM-bound workloads need a separate qualified plan.
Prepare a complete, dated backup and keep an independent copy. Stop writes or use an application-consistent backup method; copying a live directory is not proof of database consistency. Test restoration in an isolated destination. Keep the original untouched until validation.
- application migration
- supported image restore
- boot / storage drivers
- AD / cluster / TPM constraints
Inventory accounts, permissions and scheduled work
Record services and their accounts, local users/groups, NTFS ACLs, shares, scheduled tasks and firewall dependencies. Copying file contents alone may not preserve permissions, identity mappings or application credentials. Recreate only required access and test with an ordinary user as well as an administrator. Treat exported configuration and private keys as sensitive.
Prepare a destination with compatible software, enough working space for both restored data and temporary archives, and the required ports and permissions. Match versions for the first restore; plan upgrades as a separate change. A matching amount of RAM or vCPU does not prove equivalent performance.
- local users / groups / NTFS ACLs
- Windows services
- Task Scheduler
- firewall / shares
List services and scheduled tasks
Get-Service
Get-ScheduledTaskNo real migration, backup verification or compatibility test has been performed by this page. Retain the source and a tested recovery path. There is no guarantee of zero downtime, unchanged IP, transferable licences or loss-free restoration.
Back up IIS, SQL and certificates separately
Keep website files, application pools, bindings, configuration, .NET/runtime requirements and SQL backups. Export certificates with private keys only into protected storage when permitted, and verify recoverability. A copied website folder is not the IIS server configuration or a SQL database backup. Use each database engine’s supported consistent backup method.
Plan a write freeze and take a final consistent export. Transfer files and database exports separately where required. Compare file counts, sizes and checksums of the same stable archive on both sides. A matching checksum proves transfer integrity, not application consistency or completeness.
- IIS sites / application pools / bindings
- .NET / SQL Server or other SQL
- certificates + private keys
- application-consistent backup
Validate RDP and business applications privately
Prepare destination access restrictions and a recovery console before cutover. Use the assigned address and configured RDP port, not an assumed port or public unrestricted rule. Test application login, NTFS/share permissions, IIS HTTPS, SQL reads/writes, scheduled tasks and service restarts. File hashes verify identical bytes, not business-data consistency.
Test privately before opening access: startup logs, authentication, permissions, representative data, persistence after a clean restart and external dependencies. Check certificates and required TCP/UDP ports without exposing administration interfaces publicly. Keep a record of checks and unresolved differences.
- RDP access policy
- IIS HTTPS
- SQL read + write
- service / task persistence
Compare the same stable archive on each side
Get-FileHash -Algorithm SHA256 -LiteralPath 'C:\Backups\archive.zip'No real migration, backup verification or compatibility test has been performed by this page. Retain the source and a tested recovery path. There is no guarantee of zero downtime, unchanged IP, transferable licences or loss-free restoration.
Switch endpoints with a recovery decision
Schedule final exports and a controlled write freeze, then update relevant DNS and application endpoints after validation. Monitor errors, certificates, scheduled jobs and user access; avoid running the same task on both hosts. Retain protected backups and the old service until acceptance. New data created after switching must be reconciled before rollback.
Switch the published address or DNS only after the private checks. Account for TTL and caches; an IP change is normally required when changing provider. Monitor errors, resource use and new writes. Set a rollback decision point. Rolling back after new writes requires data reconciliation, not simply switching DNS back.
- final backup
- DNS / endpoints
- avoid duplicate jobs
- recovery decision
For your situation
| Situation | Next check |
|---|---|
| Before moving | Do not start the cutover until a complete backup has been restored successfully in a private test. |
| During the move | A live copy can miss concurrent changes. Plan an application-specific replication and final synchronisation procedure with a qualified administrator; no uninterrupted move is promised. |
| After switching | Keep the old host and original backups until data, connections and persistence have been checked. Decide who can authorise the switch and how to handle writes created after cutover. |
Official sources
These documents describe the relevant protocols and software. Your service terms and configuration still need to be checked.