Shared Hosting Migration Verification for Windows Server

Run the migration check before you switch traffic

Use this tutorial after a shared hosting account has been moved to a Windows Server environment and you need proof it is ready before DNS changes. The goal is shared hosting migration verification: confirm the site, mail, DNS, TLS, and Windows services are working, then keep rollback available until cutover settles.

If you are sizing the target environment or planning the next step, Hostperl’s shared hosting plans fit small-business sites that need predictable support and straightforward migration handling. For larger customer sets, pair this with the operational guidance in Shared Hosting Migration Checklist for a Clean 2026 Move and Shared Hosting Support Response Times in 2026.

This guide is written for Windows Server 2022 or Windows Server 2025 with IIS, PowerShell, Windows Firewall, and the built-in event logs. If your shared hosting platform uses Linux instead, this procedure does not apply as-is.

Start from a clean remote session

On your local computer, open an RDP session or PowerShell remoting session to the server. For a browser-based Windows control session, connect using your provider’s console. If you are on SSH-only infrastructure, this tutorial is not the right fit.

ssh root@203.0.113.10

203.0.113.10 is a reserved documentation address. Replace it with the public IP assigned to your Windows Server host. If your provider gives you a default administrator account, use that same IP with the account name they supplied.

On the VPS as root, confirm the platform and Windows build before you touch services or DNS-backed certificates.

Get-ComputerInfo | Select-Object WindowsProductName, WindowsVersion, OsName, OsVersion, CsDomain, CsDnsHostName

Successful output should show Windows Server 2022 or 2025 and the hostname that will answer after cutover. If you do not see the expected host name, stop and correct the server identity before moving on.

Check the migrated site files and app paths

For shared hosting verification, you are checking more than a home page. You need to know that the content root, uploads, and any application config files landed where IIS expects them.

Get-ChildItem -Path C:\inetpub\wwwroot -Force | Select-Object Name, Length, LastWriteTime

Replace C:\inetpub\wwwroot if your site lives in a different IIS site folder, such as a custom application path under D:\sites\example.com. You should see the expected application files, not an empty directory or an old placeholder page.

If the site depends on a custom IIS app pool identity, confirm that the application pool exists and is running.

Import-Module WebAdministration
Get-ChildItem IIS:\AppPools | Select-Object Name, State, ManagedRuntimeVersion, ProcessModel | Format-List

You want the pool for the migrated site to be Started. If it is stopped, the next section will show how to trace the cause in the event logs.

Verify IIS, bindings, and TLS before DNS changes

The most common migration mistake is assuming files alone mean success. IIS bindings, host headers, and the certificate chain must be correct before you expose the site publicly.

On the VPS as root, inspect the site bindings.

Import-Module WebAdministration
Get-WebBinding | Select-Object protocol, bindingInformation, sslFlags

Look for the expected hostname on port 80 and port 443. For example, the binding should reference example.com and www.example.com, not only the server hostname.

Next, confirm that IIS can see the certificate assigned to the HTTPS binding.

Get-ChildItem Cert:\LocalMachine\My | Select-Object Subject, Thumbprint, NotAfter | Sort-Object NotAfter -Descending

The certificate should cover the live domain and should not be expired. If you see an old certificate or a mismatch, repair it now. Do not flip DNS while TLS is broken.

From the server, test the local HTTPS response without relying on public DNS.

Invoke-WebRequest -Uri https://localhost -Headers @{ Host = 'example.com' } -UseBasicParsing | Select-Object StatusCode, StatusDescription, RawContentLength

If your site is using a different application host name, replace example.com with that domain. A healthy site returns a 200-series response or a valid redirect you expect. A 500 response usually means an app pool, permission, or config issue.

Open the Windows firewall before exposing the site

Shared hosting verification often fails because the web server works locally but blocks traffic at the firewall. Add the rules first, then test from a client network.

On the VPS as root, allow inbound HTTP and HTTPS traffic if the rules are missing.

New-NetFirewallRule -DisplayName 'IIS HTTP Inbound' -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow
New-NetFirewallRule -DisplayName 'IIS HTTPS Inbound' -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow

You should create these rules before you change DNS. If your server is already behind a provider firewall or security group, open the same ports there as well.

Confirm the rules exist.

Get-NetFirewallRule -DisplayName 'IIS HTTP Inbound','IIS HTTPS Inbound' | Select-Object DisplayName, Enabled, Direction, Action

If either rule is missing, the site may work locally and still appear down from the Internet.

Confirm mail flow and authentication records

Shared hosting migrations often break email before the website shows any obvious problem. That is why you should verify MX, SPF, DKIM, and DMARC before you cut over production mailboxes.

On your local computer, query the current live records. Replace example.com with the domain you moved.

nslookup -type=mx example.com
nslookup -type=txt example.com
nslookup -type=txt selector1._domainkey.example.com
nslookup -type=txt _dmarc.example.com

You are checking that MX points to the intended mail host, SPF includes the right sending hosts, DKIM has a published key, and DMARC exists with a policy you expect. If the old host still appears, hold the cutover.

On the server, inspect the local DNS client cache only as a sanity check. It does not replace public DNS testing, but it helps if a Windows resolver is holding stale data.

ipconfig /displaydns | Select-String -Pattern 'example.com'

For a migration with mail involved, this step is critical. A website can come up cleanly while transactional mail silently bounces.

Use logs to catch the first real failure

When a migrated shared hosting site fails, the error is usually in the IIS logs or Windows Event Log, not in the browser. Check both before you start editing config by guesswork.

Get-WinEvent -LogName Application -MaxEvents 30 | Select-Object TimeCreated, ProviderName, Id, LevelDisplayName, Message | Format-Table -Wrap

Look for application pool crashes, permission denials, or missing assemblies. If the message mentions file access, confirm the site identity can read the app directory.

icacls C:\inetpub\wwwroot

Replace the path if your site is stored elsewhere. You should see read access for the app pool identity or a group that includes it. If permissions are too broad, tighten them instead of leaving full control on the whole tree.

Run a practical smoke test from a client

Now test the migration from outside the server. This catches the difference between local success and real visitor success.

On your local computer, send a request to the live domain or temporary hosts-file target.

curl -I https://example.com

If you cannot point DNS yet, add a temporary hosts entry for verification only, then remove it after the cutover. A healthy response should show the expected status code, server header, and redirect pattern. If you see certificate warnings, stop and repair TLS before proceeding.

For a content check, fetch a known page and look for a customer-facing marker such as a title, login form, or checkout route.

curl -s https://example.com | head -n 20

Successful output should show real site HTML, not a default IIS page or a migration placeholder.

Keep rollback ready until the new host stays stable

Verification is not complete until you have tested rollback. During the first 24 to 48 hours after cutover, keep the old shared host intact, freeze content changes where possible, and preserve the old DNS zone or backup copy of the previous host config.

If the site needs a quick rollback, restore the old DNS values first. Do not delete the working migration copy until the new site has survived real traffic, mail, and a restart.

Restart-Service W3SVC
Get-Service W3SVC | Select-Object Status, Name

This confirms the IIS service comes back after a restart. You should also verify that the site still answers after the reboot test.

Test-NetConnection -ComputerName localhost -Port 443

A successful test reports TcpTestSucceeded : True. If it is false, check firewall rules, the site binding, and the certificate assignment.

Troubleshooting the most likely migration failures

Problem: the site works on localhost but not from another machine.
Diagnostic command:

Test-NetConnection -ComputerName 203.0.113.10 -Port 443

If the port test fails, the clue is usually a blocked firewall or upstream security rule. Re-check the Windows Firewall rule and any hosting-provider firewall before touching IIS.

Problem: IIS returns 500 errors after cutover.
Diagnostic command:

Get-WinEvent -LogName Application -MaxEvents 50 | Select-String -Pattern 'IIS|W3SVC|Application Error|ASP.NET'

If you see application pool identity, missing DLL, or permission clues, correct the file path or the app pool configuration, then recycle the pool.

Restart-WebAppPool -Name 'DefaultAppPool'

Replace DefaultAppPool with the pool used by your migrated site.

Problem: HTTPS works, but the browser warns about the certificate name.
Diagnostic command:

Get-WebBinding | Format-Table protocol, bindingInformation, sslFlags

The clue is a hostname mismatch in the binding. Assign the certificate to the correct IIS binding and retest with Invoke-WebRequest.

FAQ

Can I verify a shared hosting migration before changing DNS?
Yes. Test IIS locally, map the domain in a temporary hosts file, and confirm HTTPS, files, and app behavior first.

What should I check first on Windows Server?
Start with Get-ComputerInfo, then verify IIS bindings, firewall rules, certificates, and event logs.

How do I know the migration is safe to publish?
You should have a working 200-series response, correct TLS, open ports 80 and 443, mail records that resolve correctly, and a tested rollback path.

What if the new site fails after restart?
Check Get-WinEvent, confirm the app pool starts, and verify the site still passes Test-NetConnection on port 443.

Should I delete the old host right away?
No. Keep it until traffic, mail, and restarts are stable on the new server.

If you want a migration target with practical room to test and recover, Hostperl’s managed VPS hosting gives you a cleaner staging path than forcing cutovers on an undersized server.