Packing the Theme Builder: A UK Host Migration Runbook for Elementor Pro

Moving a WordPress site between UK hosts sounds like a Saturday job: zip it, dump it, repoint DNS, done. Then Elementor Pro turns up with a Theme Builder full of display conditions, a global widget every page depends on, three forms wired to SMTP, and a loop grid pulling from a custom post type. Suddenly the simple migration has more loose ends than a cable drawer.

This runbook is for the builder doing the move, not the host's one-click migrator. It assumes you can get staging access on the new host, a maintenance window, and a client who would rather hear about a planned 30-minute freeze than discover a ghost header on Monday morning.

Before you pack: audit the live site

Start with a proper inventory, not a hopeful zip. Check the PHP version, database size, uploads folder weight and whether the site relies on host-specific extras such as object cache, mu-plugins, WAF rules or image optimisation. Those extras rarely travel well.

Then list the Elementor Pro pieces that matter:

• Theme Builder templates and their display conditions.
• Global widgets and any saved templates used across pages.
• Forms, actions, SMTP settings and reCAPTCHA keys.
• Dynamic tags, custom fields and ACF field groups if they are in play.
• Custom code snippets, popups and WooCommerce templates if the site sells anything.

Also check the boring infrastructure: cron jobs, redirect rules, email DNS, SSL setup and DNS time-to-live. Lower the TTL 24 to 48 hours before cutover so the eventual switch is quick rather than a waiting game. If the domain is a .co.uk, keep the Nominet and registrar logins close; the host move and the domain move are separate jobs.

The export sequence that keeps Elementor Pro intact

Put the live site into maintenance mode before exporting. Do not rely on a plugin alone if you can set a server-level block; the point is to stop content and form entries changing mid-copy.

Take a full database dump and a complete copy of wp-content. That means uploads, plugins, themes and mu-plugins. If the new host offers a staging clone, use it, but verify what it actually copied. A host migration tool that skips mu-plugins or custom upload folders can leave you debugging a site that looks almost right.

If the URL changes, run a proper search-replace with WP-CLI or a serialisation-aware tool. Do not open the SQL file in a text editor and hope. Elementor stores data in serialised arrays, and a careless replace can break widget settings, global styles or dynamic content without throwing an obvious error.

Keep the table prefix the same unless you have a good reason to change it. Preserving page and template IDs makes Theme Builder conditions less likely to drift, especially when a full database import is used rather than a rebuild.

Import and the first staging pass

Import into staging first. Always. Disable caching and any CDN during the test so you are looking at the new host, not a cached ghost of the old one.

Once the database and files are in place, flush permalinks and open Elementor's tools. Regenerate CSS and data, then clear Elementor's cached files if the option is there. Visit the Theme Builder and confirm that headers, footers, single templates and archive templates still have their conditions. Open a global widget and check that edits propagate. Submit every form on a test page and confirm the email arrives at the right inbox — not just that the success message appears.

Check dynamic content carefully. A loop grid that pulls from a custom post type can look fine until you notice the taxonomy filter is empty. If the site uses ACF, confirm field groups and field keys survived the move. If it uses WooCommerce, test cart, checkout and any UK VAT or shipping settings before the client does.

DNS and SSL: the bit clients notice

Get SSL working on the new host before you touch DNS. Many UK hosts let you install Let's Encrypt or a paid certificate on the temporary domain, and that is exactly what you want. Test the site over HTTPS on the new server first.

Then change the DNS records. Keep email records separate and untouched unless you are deliberately moving mail as well. If Cloudflare sits in front of the domain, decide whether to keep the proxy on during cutover or switch it off briefly to reduce variables. Either way, document what you changed.

Check both www and non-www versions, and make sure the preferred version redirects cleanly. Wait for propagation without refreshing a DNS checker every 30 seconds. It will not go faster because you are staring at it.

Post-migration checks: caching, cron and the small stuff

Clear every cache layer: old host, new host, CDN, browser and any optimisation plugin. Then check the things that quietly break:

• Form deliverability, including spam folder behaviour.
• Scheduled posts and WP-Cron.
• Backups on the new host.
• Redirects from old URLs.
• Search Console and analytics tags.
• Mobile header and footer behaviour.
• Popup display conditions.
• Image optimisation and WebP delivery.

Open the site as a logged-out visitor on a phone and on desktop. Click the navigation, submit a form, and check the footer. Those three checks catch a surprising number of migration quirks before the client does.

The rollback you hope not to use

Keep the old host live for at least a week, ideally two, and do not cancel anything until the new site has been stable through a working day and a weekend. Keep the old DNS records and a recent backup somewhere sensible. If something goes sideways, you want a calm route back, not a heroic rebuild at 11pm.

A good host migration is not the one where nothing goes wrong. It is the one where the things that do go wrong are caught on staging, by you, before the client ever sees them.