Practical Guide to Website Migration in 7 Steps

A Practical Guide to Website Migration Starts with an Audit

First, find out what you are actually moving. Just the website's public_html folder is often not enough. Platforms like WordPress, Joomla, Laravel, and others store important data in a database, while separately managed services can include email, subdomains, cron jobs, SSL certificates, redirects, and DNS records.

Document the technical profile of the current environment: PHP version, database type and version, actual disk usage, monthly traffic, active plugins, caching mechanisms, and external integrations. If the website accepts online payments or orders, separate the systems that transmit webhooks, emails, or API requests as well.

At this stage, you should not assume that "the new server is definitely more powerful." For example, a new VPS may provide more resources but require server management knowledge. Shared Linux hosting might be more suitable for a website that has predictable traffic and does not need root access. The choice depends not only on speed but also on who will be responsible for updates, backups, and security.

1. Create an Independent Backup and Verify It

The backup must be complete and usable. Download the website files, export the database, save configuration files, and separately record email account and forwarding configurations. If possible, keep the backup not only inside the old hosting but also in a separate secure storage.

Do not limit yourself to a "backup completed" notification. Open the database export in a test environment, check the archive files, and make sure you have the necessary passwords for restoration. The most inconvenient time to discover a corrupted backup is after changing the DNS.

2. Prepare the New Hosting Before the Move

Create the domain, database, necessary users, and appropriate PHP configurations on the new service. If the website requires special extensions, such as ionCube, Imagick, or specific PHP modules, check them in advance. For Laravel projects, take into account the environment file, queue processing, scheduler, and folders that require write permissions.

Also, create the necessary email accounts, but do not rush to activate the change in MX records. This way, you can first make sure that the new email environment is ready without interrupting current correspondence. If you use Google Workspace or another external email service, pay close attention to preserving MX, SPF, DKIM, and DMARC records during the migration.

3. Shorten the DNS TTL and Copy the Data

Reduce the TTL 24-48 hours before the DNS change, for example, to 300 or 600 seconds. This means that after the change, internet service providers' caches will generally refresh faster. Shortening the TTL does not yield instant results because the previous high value may still be cached in some resolvers. For this reason, it must be done in advance, not at the moment of transfer.

Then, copy the files and database to the new server. For large websites, archiving files and transferring them via SFTP or rsync is often more reliable than moving thousands of small files individually. After importing the database, update the configuration: database host, name, user, and password.

If URLs are changing—for example, if the site is moving from a temporary address to the main domain—perform a controlled search and replace in the database. In WordPress, a simple text replacement can damage serialized data, so use a tool appropriate for that platform or seek the assistance of an experienced specialist.

4. Test the Website Without Public DNS Changes

Before directing visitors to the new server, test the website using the hosts file or a temporary address provided by the hosting. This allows you to open the domain with the new IP from your computer, while other users continue to see the live site.

Testing should include more than just the homepage. Open inner pages, fill out a contact form, test the search function, log into the admin panel, check image loading, and review error logs. If the website processes sales, complete the entire test order process—from the cart to the payment page and order email.

Pay special attention to these four points:

• The HTTPS certificate and its automatic renewal
• 301 redirects and the main www or non-www version
• Delivery of emails sent from contact forms
• Website speed on mobile and desktop versions

If you use Cloudflare or another CDN, do not forget that caching can hide the real problem. Temporarily clear the cache during testing or make sure you are checking the response from the new origin server.

5. Plan the Final Synchronization

Websites where data changes frequently cannot simply be copied once. A new article, order, user, or request can be added right while you are transferring the database. Therefore, choose a low-activity time, limit administrative changes, and perform a final database export.

For e-commerce or high-traffic media sites, a short maintenance mode may be required. This is a better choice than the silent loss of orders or publications. A user can accept a few minutes of a maintenance page, but is unlikely to trust a site after a disappeared payment or an unanswered request.

6. Change DNS Records and Keep the Old One Accessible

Only change A or CNAME records to the new hosting after the final synchronization. If the domain, hosting, and DNS management are with different providers, make sure in advance that you have access to all accounts and know the person responsible for the changes. Dealing with password recovery on migration day wastes time and increases the likelihood of error.

Do not turn off the old hosting immediately. Keep it active for at least 48-72 hours, and even longer for websites with complex structures or an international audience. DNS propagation can have different speeds in different regions, and during this time, the old server will protect visitors whose cache has not yet refreshed.

7. Monitor the Website in the First 72 Hours

After the DNS change, check the website from different networks and devices. Monitor uptime, server errors, PHP logs, CPU and memory usage, as well as email delivery. If the website has an analytics system, compare traffic, orders, and form submissions with data from previous days. A sharp drop is not always an SEO issue; sometimes it is simply a broken form or an incorrect redirect.

To protect SEO visibility, preserve page addresses, titles, canonical tags, and the sitemap. If the URL structure has inevitably changed, set up an appropriate 301 redirect for each valuable old address. Redirecting all old pages to the homepage is an easy solution, but it is often the wrong signal for both the user and the search engine.

Managing domain, hosting, SSL, and DNS in one place, like on Internet.am, can reduce confusion between systems during migration, especially when a small team is responsible. However, even with a single provider, the testing and backup phases should not be skipped.

A migration is successful not when the new server opens, but when the customer continues to see a fast, secure, and working website, and your team knows how to restore it in any unexpected situation.