A website migration is the process of moving a website from one environment to another. That might mean moving from one hosting provider to a different one, moving from one platform to another (say, from a custom-built site to WordPress), or moving from a development environment to production. Each scenario involves different technical steps, but most migrations share a common sequence: prepare, transfer, test, and cut over.
What follows is an account of what that process actually involves for a standard WordPress or CMS-based website migration. The specifics vary by platform, hosting environment, and site complexity, but the general structure applies broadly.
Phase One: Preparation and Inventory
Before anything moves, a migration requires a clear picture of what exists and what needs to move.
File and database audit. A CMS-based website typically has two components: the file system (PHP files, themes, plugins, uploaded media) and the database (the content, settings, and configuration stored in MySQL or a similar database). Both need to be identified, accessed, and transferred. The first step is confirming that you have access to both.
Credential collection. Migrations stall when credentials are missing. The credentials required typically include: hosting account login, SFTP or cPanel access, database credentials (host, username, password, database name), domain registrar login, and any third-party service logins (email providers, SSL issuers, CDN accounts). Collecting these before the migration starts prevents the situation where the migration is halfway through and no one can find the registrar login.
URL and redirect mapping. If the new site has a different URL structure than the old site, redirects need to be planned before the migration. Every old URL that will change needs a corresponding redirect to the new URL. This is especially important for sites with established search engine rankings, since URLs that return persistent 404 errors after migration can lose the search authority they have accumulated over time. A redirect map is a spreadsheet or document that lists old URLs and their corresponding new destinations.
Third-party integrations. Most business websites connect to external services: contact forms that send to an email or CRM, analytics tracking, chat tools, booking systems, payment processors, or marketing automation platforms. Each of these needs to be identified, and any configuration that will need to change (API keys, webhook URLs, tracking IDs) needs to be noted.
Staging environment setup. A responsible migration does not happen directly on the live site. A staging environment is a copy of the site (or the new environment) where the migration is tested before going live. The hosting provider at the destination often provides staging infrastructure, or it can be set up on a subdomain.
Phase Two: Database and File Transfer
With preparation complete, the actual transfer begins.
File transfer. The website’s file system is copied to the new host. This is typically done via SFTP using a tool like FileZilla, or via a migration plugin if the platform supports one (WordPress has several). For large sites with substantial media libraries, file transfer can take a significant amount of time, sometimes hours, depending on file size and connection speed.
Database export and import. The database is exported from the old environment (typically as a .sql file) and imported into the new environment. For WordPress sites, this involves either phpMyAdmin, the command line, or a migration plugin. The database contains all posts, pages, users, settings, and most plugin configuration data.
URL replacement in the database. When a WordPress site moves from one domain or server path to another, hardcoded URLs stored in the database need to be updated. The WordPress serialized data format means a simple find-and-replace in a text editor will corrupt the database. This step requires a tool like WP-CLI’s search-replace command or a database search-replace utility that understands serialized data. Skipping or doing this incorrectly is one of the most common causes of broken migrations.
Configuration file updates. The wp-config.php file (for WordPress) or equivalent configuration file needs to be updated to point to the new database host, name, username, and password. If the file structure on the new server is different, any hardcoded file paths may also need updating.
Phase Three: Testing Before Go-Live
This phase is the most important and most frequently rushed.
Functionality testing. Before the domain is pointed to the new server, the migrated site should be tested at the staging URL or via a modified hosts file that lets the tester preview the new server while the live site remains on the old one. Testing should cover:
- All key pages rendering correctly
- Navigation and internal links working
- Images and media loading
- Forms submitting and delivering to the correct destination
- Search functionality (if applicable)
- User login and account functionality
- Any e-commerce, booking, or payment functionality
- Third-party integrations (analytics tracking, chat tools, CRM connections)
Performance testing. The new hosting environment may be faster or slower than the old one. Running a basic speed check (via PageSpeed Insights or a similar tool) on the staged migration identifies obvious performance issues before the site goes live.
Redirect testing. If a redirect map was created, each redirect should be tested on the staging environment to confirm it returns a 301 status and resolves to the correct destination URL.
SSL verification. The new environment needs a valid SSL certificate provisioned before go-live. Testing the site at the HTTPS URL confirms the certificate is active and no mixed-content warnings exist (mixed content occurs when an HTTPS page loads resources from HTTP URLs).
Email function verification. If the site sends transactional emails (form confirmations, order receipts, password resets), those should be tested to confirm they are being sent and delivered. Email sending from a new server often requires updated SPF, DKIM, or DMARC records, and those DNS changes take time to propagate.
Phase Four: DNS Changes and Cutover
When the migrated site has been tested and confirmed functional on the new environment, the domain is pointed to the new server by updating DNS records.
DNS record update. The domain’s A record (for the root domain) and typically a CNAME record (for www) are updated at the domain registrar to point to the new server’s IP address. This change is made in the domain registrar account, not the hosting account. Confusing these two accounts is a common source of delays.
DNS propagation. DNS changes do not take effect instantly. They propagate through the domain name system over a period that can range from minutes to 48 hours, depending on the previous TTL (time to live) setting on the records and the caching behavior of various DNS resolvers. In practice, many users see the change sooner, but the full propagation window can extend longer.
During propagation, some visitors see the old site and some see the new one. This is expected. It means the old site should remain functional on the old server for the duration of the propagation window, which is typically at least 24 to 48 hours after the DNS change.
Lowering TTL in advance. If you have access to the domain’s DNS settings before the migration, lowering the TTL on the relevant records (to 300 seconds or five minutes, for example) 24 to 48 hours before the planned cutover reduces the propagation window. This is standard practice for planned migrations with a specific go-live window.
Phase Five: Post-Migration Verification
After DNS propagation is complete and the new server is serving the live site, a final round of verification confirms that the live environment matches the tested staging environment.
Live testing. Repeat the key functionality tests on the live site: forms, media, navigation, integrations, SSL, and any platform-specific features.
Analytics and tracking. Confirm that analytics tracking is firing correctly on the live domain. A migration is a common point where tracking breaks if the new environment has a different configuration.
Search Console update. If the site’s domain or URL structure changed, Google Search Console may need to be updated with the new domain or new URL structure. Submitting an updated sitemap helps Google discover the new URLs or confirm the existing ones are still present.
Old server decommission. The old server or hosting account should be kept active for a minimum of a few days after successful migration in case something surfaces that requires referencing the old environment. After confirming stability, the old account can be cancelled or decommissioned.
What Can Go Wrong and What Reduces the Risk
Common migration problems include missing credentials that surface mid-migration, database URL replacement done incorrectly, SSL misconfiguration on the new server, email sending broken by changed DNS records, and third-party integrations failing because webhook or callback URLs changed.
The mitigation for most of these is preparation and testing time. Migrations that are rushed, that skip staging testing, or that happen without a complete credentials inventory produce avoidable problems. The time spent on preparation is typically shorter than the time spent on troubleshooting an unplanned problem post-migration.
A well-executed migration is not dramatic. The site moves, the DNS updates, the tests pass, and the old environment is decommissioned. What makes that outcome consistent is the process behind it.
Related reading: How to Prevent Website Migrations from Breaking Client Email Systems, What to Do When Your Website Goes Down, and How to Hand Off Your Website to a Professional Without Losing Control of Your Business.