A WordPress migration can look simple from the outside: copy the website, point the domain, and carry on. In practice, a business site may depend on forms, email routing, analytics, search visibility, payment tools, scheduled jobs, integrations, and years of indexed URLs. Missing one dependency can turn a routine move into lost enquiries or an extended rollback.
This WordPress website migration guide gives Canadian businesses a safer way to plan the move. It covers hosting changes, domain changes, and major rebuild launches. The goal is not zero risk—no migration can promise that—but a controlled process with clear evidence, ownership, and a tested recovery path.
Define what is actually changing
Start by describing the migration in one sentence. Are you changing hosting while keeping the same domain and URLs? Moving to a new domain? Rebuilding the design while preserving the content structure? Moving from another content management system to WordPress?
The answer changes the risk profile. A hosting move with unchanged URLs is mainly an infrastructure and testing project. A domain or URL change also requires redirect mapping, search monitoring, and communication updates. A redesign introduces another layer of variables, so it is usually safer to separate the visual overhaul from the move when possible.
Google’s guidance for site moves with URL changes recommends changing one major thing at a time when practical. That makes failures easier to isolate and gives search systems a clearer transition to process.
Write down the business objective, what will change, what must remain unchanged, the launch window, the person who can approve a rollback, and the measurable conditions for success.
Inventory the current website and its dependencies
Do not begin with the migration plugin. Begin with an inventory. List the WordPress version, theme, child theme, active plugins, custom code, PHP version, database size, uploads size, and hosting configuration.
Then map everything outside WordPress that still affects the site:
- domain registrar and DNS provider;
- email hosting and relevant DNS records;
- analytics, tag management, and advertising pixels;
- Search Console and other ownership-verification methods;
- contact, quote, newsletter, booking, and checkout forms;
- payment gateways, shipping tools, tax services, and webhooks;
- SMTP, transactional email, and customer notifications;
- caching, content delivery, firewall, and security services;
- scheduled tasks, feeds, APIs, and third-party embeds; and
- downloadable files or assets served from a separate location.
Capture current settings and successful test results before the move. A screenshot of a working form confirmation, for example, gives the team a concrete behaviour to reproduce after launch.
This inventory also helps decide whether the project belongs inside routine website maintenance after launch or needs a dedicated migration plan with development and SEO support.
Build backups you can actually restore
A migration backup should include the database, themes, plugins, uploads, configuration files, custom code, and any server rules the site depends on. Keep a copy outside both the old and new hosting accounts so one provider problem cannot remove every recovery option.
The official WordPress migration documentation starts a server move with backups of the site files and database. That is the baseline, not the entire recovery plan.
Record when the backup was created, who created it, where it is stored, and which credentials are required to restore it. For a busy store or lead-generation site, decide how content submitted after the backup will be handled. Orders, form entries, comments, bookings, and account changes can continue while the team prepares the new environment.
Most importantly, test the restore on a safe environment. A backup file that has never been restored is evidence of a backup attempt, not proof of recoverability. Pair the migration work with the controls in a practical WordPress security checklist so temporary accounts, copied credentials, and staging environments do not become new risks.
Prepare and test the destination environment
Set up the destination before changing public DNS. Match or deliberately update PHP, database, web-server, and caching requirements. Confirm the new host supports the site’s plugins, mail method, storage needs, scheduled tasks, and expected traffic.
Use a staging URL or a controlled local hosts-file method to review the copied site without sending customers to it. If the staging environment is publicly reachable, protect it and prevent search indexing. Remember to remove any temporary noindex or blocking rules before launch.
Test representative templates rather than only the homepage:
- the homepage and primary navigation;
- service, landing, blog, archive, and search pages;
- contact and quote forms, including confirmation emails;
- login, password reset, account, cart, and checkout flows when present;
- redirects, 404 behaviour, PDFs, images, and downloads;
- mobile layouts, keyboard navigation, and browser zoom; and
- caching, performance, security headers, and SSL behaviour.
Compare the new environment with a current WordPress speed optimization baseline. A faster server does not help if caching breaks personalized pages, scripts fail to load, or large layout shifts appear after deployment.
Protect URLs, redirects, and search signals
If the public URLs will remain identical, verify that WordPress home and site settings, canonical tags, internal links, media URLs, sitemap output, and robots directives still point to the live domain.
If URLs will change, create an old-to-new mapping before launch. Every valuable old URL should redirect directly to its closest relevant destination using a permanent server-side redirect. Avoid sending every retired page to the homepage, creating redirect chains, or relying on JavaScript redirects.
Keep equivalent page content and metadata aligned where possible. Update internal links, canonical tags, XML sitemaps, structured data, hreflang where used, analytics settings, and paid campaign destinations. Preserve Search Console verification on both properties.
For a domain move, Google’s Change of Address tool is used after the site has moved and redirects are active. It is intended for domain or subdomain changes, not an ordinary hosting change where the visible URL stays the same.
Export a crawl or URL list before launch and crawl the new site again afterward. This gives you a concrete way to find missing pages, unexpected status codes, redirect chains, incorrect canonicals, and links that still point to staging.
Plan DNS, email, and the launch window
DNS changes are only one part of the cutover. Identify the authoritative DNS provider, lower time-to-live values in advance when appropriate, and document the exact records that must remain. Take special care not to overwrite mail exchange, SPF, DKIM, DMARC, verification, or service records when changing the website’s address record.
Choose a lower-traffic launch window that still leaves the right people available. A late-night launch is not automatically safer if the developer, host, email administrator, or business owner cannot respond when a problem appears.
Prepare a communication plan with the launch start, expected customer impact, owners, escalation contacts, go/no-go checkpoint, and rollback deadline. Freeze non-essential content changes during the final transfer so the old and new databases do not quietly diverge.
Use a controlled launch sequence
A practical cutover sequence is:
- confirm the approved backup and restore point;
- enable a short content or order freeze if required;
- synchronize the final database and changed files;
- verify production URLs and remove staging-only restrictions;
- update DNS or routing;
- purge server, plugin, CDN, and browser-facing caches;
- test the homepage and one inner page over HTTPS;
- submit every important form and verify delivery;
- complete login, checkout, booking, or payment tests that apply;
- crawl critical URLs and test redirect samples;
- confirm analytics, consent, pixels, and Search Console access; and
- record the result and either approve the launch or execute rollback.
Use more than one network or DNS resolver when checking the cutover. DNS propagation can make the site appear correct for one team member while another still reaches the old server.
Monitor after launch instead of declaring victory
The first successful page load is the start of post-launch verification. Watch uptime, server errors, PHP logs, form delivery, orders, transactions, scheduled jobs, security alerts, traffic, and search coverage.
Check high-value URLs daily during the initial period. Compare leads or transactions with the normal business pattern, but avoid drawing conclusions from a few hours of data. For URL-changing moves, expect search systems to recrawl the old and new locations over time.
Keep the old hosting and backups available until the agreed observation period has passed and the owner has approved decommissioning. Do not allow two editable production copies to remain active; that creates confusion about which database is authoritative.
Document the final DNS values, hosting account, credentials owner, backup schedule, license ownership, monitoring tools, known exceptions, and next renewal dates. This handoff matters as much as the transfer itself.
Know when a managed migration is worth it
A small brochure site may be moved with a short checklist. A store, membership site, multilingual website, learning platform, high-traffic publication, custom integration, or domain change usually deserves deeper planning and specialist testing.
Professional support is also valuable when the current host is unstable, the site has been compromised, there is no tested backup, email shares the same DNS zone, or the internal team cannot safely validate forms and transactions.
Nexxen Studio’s WordPress and website services can combine migration planning with maintenance, performance, design, and post-launch support. If you are preparing a host, domain, or rebuilt-site move, contact Nexxen Studio with the current platform, destination, target date, and the business journeys that cannot fail.
A successful migration is not the one that finishes fastest. It is the one that preserves the website’s content, customer journeys, search signals, and recovery options—and leaves the business with a clearer system than it had before.
