Moving a website to a new provider can improve performance, support, or cost control. However, the move should follow a website hosting migration checklist without downtime, not a rushed file copy. The safest process builds a working copy, protects the original site, prepares DNS, synchronizes changing data, and defines rollback steps before traffic moves.
Start with a complete migration inventory
First, record everything the current website uses. A WordPress site includes more than its visible pages. It may depend on a database, scheduled tasks, uploads, forms, payment tools, email services, external APIs, and custom server settings.
Document the current provider, server address, PHP version, database type, web server, SSL settings, caching layer, CDN, DNS provider, and domain registrar. Also list every subdomain, such as www, shop, portal, or staging.
- Export the current DNS records and note their purpose.
- Record WordPress core, theme, and plugin versions.
- Identify forms, ecommerce transactions, memberships, and user registrations.
- List cron jobs, server-side redirects, rewrite rules, and scheduled backups.
- Confirm who can access the registrar, DNS provider, old host, and new host.
This inventory becomes the baseline for testing. It also prevents a forgotten subdomain or scheduled task from failing after the move. For broader coordination, see this website hosting migration plan.
Build and test a staging copy
Staging is a private working copy of the website. It lets you test the new server without changing the public site. Create staging at the new host when possible, then restrict access with host controls, authentication, or an IP allowlist.
Copy the website files and database into the new environment. Update the configuration with the new database name, username, password, and host. Do not reuse credentials casually. Use separate secrets for staging and production, and keep them out of public notes.
The staging site should use a temporary hostname or host-file test. Avoid changing public DNS merely to preview the site. Check that WordPress generates the correct URLs, images load, permalinks work, and administrator access remains available. This is a central step in a website hosting migration checklist without downtime.
Match the important server settings
Compare PHP versions, memory limits, upload limits, extensions, web server rules, and database settings. A new host may apply different defaults. Those differences can expose plugin bugs or change how uploads and rewrites behave.
Review caching carefully. Clear application, server, CDN, and browser caches during testing so you can see current results. Official WordPress performance guidance can help you separate hosting issues from application bottlenecks.
Protect the original site with verified backups
A backup is useful only if you can restore it. Before migration, create an independent copy of the files and database. Store it somewhere separate from both hosting accounts. Keep the original site online until the new site passes its checks.
Take another backup immediately before the final synchronization. Include uploads, configuration files, database data, certificates where appropriate, and any custom scripts. Record the backup time and retention location. A complete website hosting migration checklist without downtime treats restoration as a testable process.
Perform a test restore before the cutover if the site supports important business activity. At minimum, confirm that the archive opens, the database imports, and the restored files have the expected ownership and permissions. A backup that cannot be located or restored should not be treated as a rollback plan.
Prepare DNS and certificate details early
DNS, or the Domain Name System, directs a domain to services such as a website or mail platform. Review the existing records before changing anything. Pay particular attention to the root domain, www, verification records, CDN records, and any subdomains.
Prepare the new host’s target records in advance. If the provider supports a temporary URL, test that first. Otherwise, use a temporary hostname or controlled local resolution. Do not change the live record until the new site is ready.
Check SSL coverage for every public hostname. The certificate must include the names visitors use, including redirects between the root domain and www. Confirm how the new provider issues and renews certificates. A certificate may not issue until DNS points to the new service.
DNS caches can preserve old answers after a change. Timing therefore matters. Use the provider’s documented TTL behavior and allow for resolver differences. This DNS timing guide provides useful planning context.
Synchronize files and database data
A simple copy works only when the site remains unchanged during the move. Active websites create new data while you prepare them. Contact forms may receive messages, stores may receive orders, and users may update profiles.
Use a two-pass process. Copy the site to staging first. Then, close or pause activities that write important data during the final window. Take a fresh database export and copy changed uploads again. Import the fresh database into the new host, then verify its table prefixes, character encoding, and connection settings.
For ecommerce or membership sites, maintenance mode may be safer than allowing writes during synchronization. Tell staff when the pause begins. Record any orders, form submissions, or account changes that require manual reconciliation.
Do not overwrite the production database blindly. Confirm the destination and backup before importing. Database commands and migration tools vary by host, so follow the provider’s instructions and verify each result.
Test the new host before switching traffic
Use a written test list rather than relying on a quick homepage check. Test from more than one network and browser. Review both visitor functions and administrative tasks.
- Load the homepage, key landing pages, posts, images, and downloads.
- Test navigation, search, permalinks, redirects, and 404 handling.
- Submit every important form and confirm delivery to the correct mailbox.
- Test login, password reset, roles, publishing, media uploads, and editing.
- Check ecommerce checkout, payment handoff, webhooks, and confirmation messages.
- Confirm analytics, consent tools, APIs, scheduled tasks, and integrations.
- Inspect page source for mixed-content warnings and incorrect absolute URLs.
- Review server logs for PHP errors, missing files, failed requests, and database warnings.
Compare representative pages against the old site. Check titles, canonical URLs, metadata, structured data, and robots settings. Keep search visibility in mind while testing; a staging copy should not accidentally become indexable.
Plan the traffic cutover
Choose a quiet period that leaves time for observation. Notify people who handle orders, forms, publishing, and customer support. Freeze content changes shortly before the final synchronization.
Run the last backup and database sync. Update the required DNS records, then monitor both the old and new hosts. During propagation, different visitors may reach different servers. The old site must remain functional until traffic has settled.
Use external checks to test resolution, HTTPS, redirects, forms, and major pages. Check the site from office networks, mobile connections, and at least one independent monitoring location. Look for errors rather than assuming success because the homepage loads.
Keep the old hosting account active for an agreed observation period. Do not cancel it immediately after DNS changes. Preserve logs and access while you confirm traffic, transactions, and scheduled processes on the new host.
Define rollback before the migration starts
Rollback means returning traffic to the old environment when the new one fails an important check. Write the decision rules before the cutover. Examples include failed checkout, missing customer data, broken forms, certificate errors, or severe application errors.
Record the previous DNS values, the time of the change, and the person authorized to reverse it. If you reverse DNS, remember that caches may delay the result. Keep the old site unchanged while you decide whether to roll back.
Rollback becomes harder after new data reaches the destination. For that reason, capture orders, submissions, registrations, and other changes before switching back. Reconcile those records carefully once the service is stable.
After a successful move, save the final configuration, test results, credentials location, DNS export, and rollback notes. Good documentation makes the next change safer and gives support staff evidence when something behaves differently.
When professional migration help makes sense
A small brochure site may move with a short maintenance window. Active stores, membership sites, and business portals need more control. If you cannot test a restore, access DNS confidently, or identify which systems write to the database, pause before changing traffic. Tech Rescue Ops LLC can help coordinate staging, synchronization, DNS checks, testing, monitoring, and recovery planning. This website hosting migration checklist without downtime gives the migration a controlled path forward.