Moving a website from one hosting provider to another requires great care. If done quickly without planning, the website may stop opening, email may stop working, the database may be lost, SSL may show “Not Secure,” images may disappear, forms may fail to send messages, or Google may find indexing errors. That is why website migration needs a good checklist before, during and after the move.
Many people think migrating a website means copying files only. But most websites have much more: domain, DNS records, database, email accounts, SSL certificate, media files, environment variables, redirects, cron jobs, backups, permissions, CMS settings, cache, analytics, payment integrations and SEO settings. If you forget one item, the website can break.
The first step is identifying the type of website you are moving. A simple HTML website may need only files. WordPress needs files and database. Django, Laravel or Node.js websites need code, database, media files, environment variables, dependencies, static files and server configuration. An e-commerce website may need payment settings, order data, customer accounts and more security checks.
The second step is preparing a migration plan. Do not migrate without a plan. Write down the old hosting, new hosting, domain registrar, DNS provider, email provider, database type, storage location, SSL setup and all important access details. Make sure you have logins for both hosting accounts, domain account, email admin and database access. Without these, you can get stuck halfway.
The third step is choosing a good migration time. Do not migrate during high traffic or when the business depends on many orders. Choose a time when visitors are fewer, such as night or a low-activity day. For business websites, inform the team early so they do not make updates while migration is happening.
The fourth step is reducing TTL before migration. TTL is how long DNS records remain in cache. If TTL is high, DNS changes may take longer to spread. A day or several hours before migration, reduce TTL for important records such as A record and CNAME so IP changes spread faster. Do not wait until the last minute if the website is important.
The fifth step is making a full backup. This is the most important step. Before moving anything, back up all files, database, emails if stored on hosting, media uploads, configuration files, SSL keys if needed and important settings. Store the backup somewhere separate from the old hosting, such as your computer, external drive or cloud storage.
The sixth step is verifying the backup. A backup you have not checked is not fully reliable. Open the backup file and confirm it contains important folders, media files, database dump and config files. For the database, make sure export completed without errors. For WordPress, make sure wp-content exists. For Django, make sure media folder, requirements file and .env sample exist.
The seventh step is preventing content changes during migration. If the website has blog posts, orders, comments, payments or user registrations, data may change while you are migrating. You can enable maintenance mode or temporarily stop updates. This helps prevent losing new data added to the old hosting after backup.
The eighth step is copying files to the new hosting. For a normal website, use File Manager, FTP, SFTP or command line. For a large project, use Git deployment or rsync. Make sure all important folders are moved, especially uploads, media, static files, themes, plugins and custom files. Do not move unnecessary cache if it can be regenerated.
The ninth step is moving the database. Export the database from old hosting, then import it into new hosting. For MySQL or MariaDB, use phpMyAdmin, command line or a database tool. For PostgreSQL, use pg_dump and restore. Make sure database charset and collation are preserved, especially if the website contains Swahili or special characters.
The tenth step is updating database connection settings. The website must know where the new database is. Change database name, username, password, host and port in the configuration. In WordPress, this is in wp-config.php. In Django or Laravel, it is often in .env. Do not use old credentials if the database moved to a new server.
The eleventh step is moving environment variables. Modern websites use .env for settings such as SECRET_KEY, DEBUG, database URL, email SMTP, payment keys, API keys, allowed hosts and storage settings. Make sure all environment variables are configured on the new hosting. Do not lose secrets, but also do not expose them publicly on GitHub or unsafe places.
The twelfth step is setting file permissions. Some hosting environments need correct permissions so the website can read files and write uploads or cache. Wrong permissions can cause images not to load, uploads to fail or 403/500 errors. Avoid dangerous permissions such as 777 unless absolutely necessary. Use safe permissions based on your hosting environment.
The thirteenth step is installing dependencies. For WordPress, make sure plugins and theme files exist. For Django, install requirements. For Laravel, install Composer dependencies. For Node.js, install packages. Make sure the Python, PHP, Node or database version on the new hosting matches the project. A different version can break the website.
The fourteenth step is testing before changing DNS. Do not point the domain to new hosting before testing the website. Use a temporary URL, staging domain, subdomain or hosts file on your computer to check the website on the new server without affecting public users. This is professional migration.
The fifteenth step is using the hosts file for testing. You can make your computer see the domain as pointing to the new IP without changing DNS for everyone. This helps test the website as if it is live on the real domain, but only from your computer. It is slightly advanced, but very useful for finding errors before the official move.
The sixteenth step is testing important pages. Do not test only the homepage. Open About, Contact, Blog, Product pages, Login, Register, Dashboard, Checkout, Search, Forms, Images, Downloads and Admin. A website may open the homepage but have errors elsewhere. Test whether links work and there are no unexpected 404 errors.
The seventeenth step is testing forms. Contact forms, order forms, registration forms, newsletter forms and payment forms must be tested. Make sure forms send email or save data into the database. Migration often breaks SMTP settings, CSRF settings, permissions or API keys, and forms stop working without being noticed early.
The eighteenth step is testing email. This is where many people break things. If your emails use the old hosting, changing nameservers or DNS without moving MX records can stop email delivery. Before changing DNS, write down all email records: MX, SPF, DKIM, DMARC, mail subdomain and webmail records.
The nineteenth step is deciding where email will stay. You can move only the website while keeping email at the old provider. In that case, DNS email records must continue pointing to the old email provider. Or you can move both website and email to new hosting. Then you must migrate mailboxes, passwords, forwarders and email client settings. This decision must be made before DNS changes.
The twentieth step is making sure SPF, DKIM and DMARC are correct. These are important DNS records for email deliverability. SPF shows which servers are allowed to send email for your domain. DKIM helps sign email. DMARC helps define verification policy. If you forget these, your emails may go to spam or be rejected.
The twenty-first step is setting SSL on the new hosting. Before or right after the domain points to the new hosting, make sure an SSL certificate is available. Many hosts offer Let’s Encrypt. If the domain has not yet pointed to the new hosting, SSL may fail to issue until DNS changes. After DNS changes, enable SSL and force HTTPS.
The twenty-second step is checking mixed content. After SSL is installed, the website may still show Not Secure if images, CSS, JavaScript or links use HTTP. Change old links to HTTPS. For WordPress, you may need search and replace of the old URL. For custom websites, check templates and database content.
The twenty-third step is setting correct redirects. If the domain version changes from www to non-www or HTTP to HTTPS, set redirects. All versions should end at one main version. This is important for SEO and user experience. Do not leave the website accessible on both HTTP and HTTPS without structure.
The twenty-fourth step is preserving URL structure. If you are only changing hosting, do not change slugs and URLs without reason. Google already knows your pages. If you change URLs without redirects, you will get 404 errors and SEO may drop. If URLs must change, set 301 redirects from old URLs to new ones.
The twenty-fifth step is moving all media files. Many websites break after migration because images or downloads were not moved. For WordPress, wp-content/uploads is very important. For Django, the media folder is important. For e-commerce, product images and downloadable files are important. Make sure these files moved and have correct permissions.
The twenty-sixth step is checking cache. Cache can show the old version or create errors after migration. Clear website cache, plugin cache, browser cache, CDN cache and server cache. If you use Cloudflare, purge cache after migration. Do not forget that cache can make you see the old website while others see the new one.
The twenty-seventh step is setting cron jobs or scheduled tasks. Some websites depend on cron jobs for backups, emails, reports, payment checks, subscriptions or cleanup. If you forget cron jobs, the website may appear to work but important tasks will stop. Write down cron jobs from old hosting and recreate them on new hosting.
The twenty-eighth step is checking payment integrations. If the website receives payments, test the payment flow. Make sure callback URLs, webhook URLs, API keys, IPN settings and return URLs match the new hosting. Sometimes the gateway requires a public HTTPS URL. Do not allow the website to receive payments without testing.
The twenty-ninth step is changing DNS. After testing, backup and setup are complete, change the A record or nameservers based on your plan. Often, changing only the A record is safer if the old DNS provider contains all email records. Changing nameservers can be risky if you have not copied all records. Make sure you know what you are changing.
The thirtieth step is monitoring after DNS change. After the domain points to the new hosting, monitor the website for 24 to 48 hours. Test from different devices, networks and browsers. Check logs, forms, emails, checkout, admin, SSL and important pages. Do not delete the old hosting too quickly until everything is confirmed.
The thirty-first step is checking Google Search Console. After migration, check for crawl errors, 404 pages, indexing issues or sitemap problems. Make sure the sitemap uses HTTPS URLs and the correct domain version. Submit the sitemap if needed. This helps Google understand that your website is working correctly after migration.
The thirty-second step is checking analytics. Make sure Google Analytics or any tracking tool still works. Sometimes migration removes tracking code or plugins. Without analytics, you will not know whether traffic dropped or pages have problems. Test real-time visits if your tool supports them.
The thirty-third step is keeping the old hosting for a while. Do not delete the old hosting on the same day. Keep it for several days or a week depending on the website’s importance. If there is a file or database record you forgot, you can still retrieve it. If you delete it too early, recovery can be difficult.
The thirty-fourth step is making a new backup after migration. After the website works on the new hosting, create a fresh backup of the current state. This becomes your new restore point. Also set a backup schedule on the new hosting so you do not rely on the old backup.
The thirty-fifth step is writing a migration report. Record the migration date, old hosting, new hosting, DNS changes, database name, email decision, SSL status, issues found and solutions. This will help later if you need to migrate again or fix a problem that appears after some time.
In general, website migration is not just copy and paste. It requires backup, testing, DNS planning, email protection, database transfer, SSL setup, redirect management, SEO checks and post-migration monitoring. If done step by step, you can move a website without major downtime and without losing email or important data.
Remember: do not change nameservers without knowing email records. Do not delete old hosting without backup. Do not move a website without testing on the new server. And do not forget that a website may open while email, forms or payments are broken. A good migration tests every important part before declaring the work complete.