Last Updated on 19/09/2026 by Rahul Baghora
Changing web hosts can improve performance, reliability, support, or cost efficiency, but the migration itself introduces risk. A website may depend on much more than the visible files stored in the document root.
DNS records, SSL certificates, databases, email routing, scheduled jobs, redirects, caching, environment variables, PHP modules, and server-specific configuration can all affect whether the site works correctly after the move.
A structured migration checklist helps reduce downtime and makes rollback easier if something unexpected happens.
Document the Existing Hosting Environment First
Before copying anything, record how the current server is configured.
Note the operating system, web server, PHP version, database version, document root, enabled modules, cron jobs, storage usage, and any server-level redirects or security rules.
This creates a reference for comparing the old environment with the new one.
List Every Domain and Subdomain
A hosting account may serve more than one hostname.
Include the main domain, www version, staging addresses, API subdomains, mail-related names, CDN hostnames, and any legacy domains that still redirect traffic.
Missing one active subdomain can create failures that are not immediately visible from the homepage.
Record the Current DNS Zone
Export or manually document the existing DNS records before changing nameservers or individual records.
Important entries can include A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, verification records, and service-specific subdomains.
Do not assume the new hosting provider will automatically recreate all of them.
Know Where DNS Is Actually Managed
The domain registrar, DNS provider, CDN, and web host may all be different companies.
Before migration, identify which service currently controls the authoritative DNS zone.
This prevents last-minute confusion when it is time to change records.
Keep Hosting and Infrastructure Resources Easy to Revisit
A migration often involves moving between hosting dashboards, registrar accounts, SSL tools, DNS panels, monitoring services, and technical documentation.
For general navigation among frequently used web resources, a reference point such as 주소모음 바로가기 can help keep useful destinations easier to revisit, while registrar access, DNS changes, server credentials, billing, and other sensitive operations should always be handled through verified official provider pages.
Lower DNS TTL Before the Migration
If the DNS provider allows it, reducing the TTL before the planned cutover can help changes propagate more quickly.
Do this in advance rather than immediately before switching servers, because existing resolvers may continue to use previously cached values until their old TTL expires.
Do Not Change DNS Too Early
The new server should be fully prepared and tested before public traffic is directed to it.
Changing the A or AAAA record before the application is ready can turn a controlled migration into an unexpected outage.
Create a Complete File Backup
Copy all website files before making changes.
Do not include only visible HTML, PHP, images, or application files. Hidden files such as .htaccess and configuration files may contain critical rewrite, security, or routing rules.
Back Up the Database Separately
A file backup is not a database backup.
Export MySQL, MariaDB, PostgreSQL, or other databases separately and verify that the dump can actually be read.
For a dynamic site, the database may contain most of the content and configuration.
Record Database Connection Settings
The new environment may use a different database hostname, username, password, port, or database name.
Identify where those values are stored in the application before moving it.
Consider Database Character Sets
Encoding differences can create broken characters after migration.
Check the database character set and collation, especially for multilingual websites.
Check Database Version Compatibility
A large version jump between database servers may affect SQL modes, reserved words, authentication methods, or application behavior.
Verify that the CMS or application supports the version available on the new host.
Freeze High-Change Content if Necessary
Sites that receive orders, comments, registrations, or frequent content updates can change while the migration is taking place.
For a busy application, plan how to prevent new data from being lost between the final database copy and DNS cutover.
Create More Than One Backup Copy
A migration backup should not exist only on the server being replaced.
Keep at least one independent copy in another controlled location so the data remains available if the old account becomes inaccessible.
Verify the Backup Before Depending on It
A backup is useful only if it can be restored.
Check archive integrity, database dump size, file counts, and critical configuration files before continuing.
Review PHP and Runtime Versions
The new host may default to a newer or older PHP version.
Check whether the application, CMS, plugins, themes, and custom code support the selected version.
A migration is not the ideal moment to discover that an old plugin fails on the new runtime.
Check Required PHP Extensions
Applications may rely on extensions for image processing, database connectivity, encryption, XML, ZIP archives, multibyte text, or other functions.
Compare enabled modules between the old and new servers.
Review Web Server Differences
Moving from Apache to Nginx, or the reverse, can change how redirects, rewrites, access restrictions, and configuration files work.
Rules stored in .htaccess will not automatically behave the same way on every server stack.
Copy Redirect Rules Carefully
Existing 301 redirects may preserve old URLs, marketing campaigns, or previous site structures.
Losing those rules during migration can create unnecessary 404 errors and broken inbound links.
Preserve Canonical URL Behavior
Decide whether the site uses HTTP or HTTPS, www or non-www, trailing slashes, and other URL conventions.
The new environment should maintain the same preferred behavior unless a deliberate change is planned.
Prepare SSL Before Public Cutover
The new server should be ready to serve HTTPS correctly before users reach it.
Depending on the certificate authority and validation method, certificate issuance may require DNS or HTTP validation.
Check Every Hostname on the Certificate
A certificate for the root domain does not automatically cover every possible hostname.
Confirm that www and any HTTPS subdomains are included where necessary.
Test the Certificate Chain
An incomplete certificate chain can work in some environments while producing warnings in others.
Verify that the server provides the full required chain and that the certificate has not expired.
Do Not Forget Automatic SSL Renewal
A certificate working on migration day is not enough.
If the host uses automated certificate renewal, verify that the renewal mechanism is enabled and capable of completing validation later.
Check HTTP-to-HTTPS Redirects
After SSL is working, confirm that HTTP requests reach the correct HTTPS destination.
Avoid unnecessary redirect chains such as HTTP to www HTTPS and then to non-www HTTPS when a direct redirect is possible.
Review Email Before Changing DNS
Moving the website does not always mean moving email.
If email is hosted elsewhere, existing MX and related TXT records must remain intact.
Replacing the DNS zone without preserving them can interrupt mail even when the website itself works perfectly.
Preserve SPF, DKIM, and DMARC Records
Email authentication records are easy to overlook during DNS migration.
Document them before the cutover and confirm they remain present afterward.
Check Contact Forms
Website forms may depend on local mail delivery, SMTP credentials, an API, or a third-party transactional email service.
Test form submissions from the new server before declaring the migration complete.
Review Cron Jobs and Scheduled Tasks
Scheduled tasks may send reports, process queues, refresh feeds, clear temporary files, or run backups.
Cron configuration does not necessarily migrate with the website files.
Recreate required jobs on the new host and verify their paths and runtime versions.
Check File Permissions and Ownership
Different servers can use different users and permission models.
Incorrect ownership may prevent uploads, cache generation, plugin updates, or log writing.
Avoid solving permission problems by making everything broadly writable.
Confirm Writable Directories
CMS platforms and applications often require specific directories for uploads, cache files, sessions, or temporary data.
Test those functions explicitly after moving the files.
Review Environment Variables and Secrets
Applications may use environment variables for API keys, database credentials, payment integrations, or email services.
These values may be configured outside the application directory and therefore excluded from a normal file copy.
Check External API Restrictions
Some APIs restrict access by server IP address.
If the new host has a different public IP, update any allowlists before cutover.
Review Firewall Rules
Server firewalls, cloud security groups, and application firewalls may restrict incoming or outgoing connections.
Confirm that required ports and trusted services are allowed without exposing unnecessary access.
Test the New Server Before DNS Changes
The safest migration allows the website to be tested on the new server while public DNS still points to the old one.
This can be done with a temporary hostname, preview environment, or local hosts-file override depending on the setup.
Test More Than the Homepage
A homepage returning HTTP 200 does not prove that the migration succeeded.
Test internal pages, login, search, forms, uploads, dynamic content, redirects, images, CSS, JavaScript, API endpoints, and administrative functions.
Check for Hard-Coded Old URLs
Applications sometimes store absolute URLs in databases or configuration files.
Review the site for references to an old hostname, temporary migration domain, or server IP before going live.
Check Mixed Content
An HTTPS page that loads scripts, styles, images, or other resources over HTTP may generate browser warnings or blocked requests.
Test representative pages after SSL is enabled.
Test Mobile and Desktop Views
A server migration can expose missing assets, caching issues, or application errors that affect only certain templates.
Check important page types on both desktop and mobile browsers.
Compare Response Headers
Server migrations may change compression, caching, security headers, or CDN behavior.
Compare important headers between the old and new environments where relevant.
Review Caching Layers
A site may use application cache, page cache, object cache, reverse proxy cache, CDN cache, or several layers at once.
Understand which parts belong to the old host and which need to be recreated.
Clear Cache During Final Testing
Old cached HTML or assets can make a broken migration appear successful or make a successful migration appear broken.
Purge relevant caches when validating the new environment.
Check CDN Configuration
If a CDN or proxy service sits in front of the site, verify the origin server, SSL mode, cache rules, firewall configuration, and DNS relationships.
The CDN may continue directing traffic to the old server until its origin settings are changed.
Monitor Resource Usage on the New Host
A site that works during a small test may behave differently under real traffic.
Watch CPU, memory, disk I/O, database load, connections, and storage after public traffic moves to the new environment.
Prepare Uptime Monitoring Before Cutover
Set up an external monitor for the main site and, where useful, important endpoints.
External monitoring can reveal availability problems immediately after DNS changes.
Monitor HTTP Status, Not Just Ping
A server can respond to network requests while the web application returns an error.
Monitoring an actual HTTPS URL provides a better indication of whether visitors can use the site.
Check DNS From Multiple Resolvers
After changing records, different networks may resolve the domain to different IP addresses temporarily.
Check public DNS responses from more than one resolver during the transition.
Keep the Old Server Online Temporarily
Do not cancel the previous hosting account immediately after changing DNS.
Some visitors or services may continue reaching the old server while cached DNS records expire.
Keeping it available also provides a useful rollback option.
Plan the Rollback Before You Need It
Decide what conditions would justify returning traffic to the previous server.
Know which DNS records need to be restored and preserve an unchanged copy of the old environment until the new one has proven stable.
Watch Application Logs After Launch
Server and application logs can reveal missing files, permission errors, database problems, failed API calls, and other issues that users may not report immediately.
Review them during the first period after the switch.
Check 404 Errors
A spike in 404 responses after migration may indicate missing redirect rules, incorrect document roots, case-sensitivity differences, or files that were not copied.
Test Database Writes
A site can display existing content even when database writes fail.
Test actions that create or update data, such as account changes, form submissions, CMS edits, or transactions when applicable.
Verify Uploads
File uploads exercise storage paths, permissions, PHP limits, and application configuration.
They are therefore a useful post-migration test.
Compare Performance Before and After
Record baseline response times or other relevant performance measurements before moving.
After migration, compare similar pages under similar conditions rather than relying only on subjective impressions.
Do Not Optimize Everything During the Same Migration
Changing hosting, application versions, URL structure, caching, database configuration, and design at the same time makes failures harder to diagnose.
Whenever practical, separate infrastructure migration from unrelated major changes.
Restore Normal DNS TTL Later
Once the new environment is stable, TTL values that were temporarily reduced can be returned to an appropriate normal setting.
Very low TTL values are not always necessary for long-term operation.
Final Migration Checklist
- document the current server configuration
- export the complete DNS zone
- back up files and databases independently
- verify PHP, database, and module compatibility
- preserve redirects and canonical behavior
- prepare SSL and renewal on the new server
- preserve email-related DNS records
- recreate cron jobs and environment variables
- test the new host before changing public DNS
- verify forms, uploads, logins, redirects, and database writes
- configure monitoring and review logs
- keep the old environment available for rollback
A Successful Hosting Migration Is Mostly Preparation
The DNS change itself may take only a few seconds. Most of the important work happens before and after that moment.
A reliable migration depends on understanding the existing environment, preserving data, preparing SSL and DNS correctly, testing application functions, and keeping a clear rollback path.
When each dependency is documented and verified before public traffic moves, changing web hosts becomes a controlled infrastructure task rather than an emergency troubleshooting session.
About The Author
