A host migration is usually judged on whether the site looks right and the forms work. Consent is judged later, by an audit or a complaint, when someone discovers the banner on the new host is a fresh install with default settings, no blocking rules, and a consent record history that stayed behind on the old server.
The failure is understandable. Consent configuration is scattered across plugin settings, database tables, code snippets, and third party dashboards, and standard migration tools copy what they recognize. A deliberate consent checklist for the move is cheap insurance against rebuilding the whole setup under pressure.
Inventory the consent setup before moving anything
List every component on the old site: the consent plugin and its version, where its settings and consent logs live, custom blocking rules and script categories, banner customizations and CSS, region and language variants, and integrations with analytics, tag managers, and advertising tools.
Note which pieces live outside WordPress entirely, such as tag manager consent configuration, because a site migration that changes nothing there can still break the connection if URLs, container IDs, or loading order shift during the move.
Migrate settings and records, do not just reinstall
A fresh install of the same consent plugin is not a migration. Settings may look similar at defaults while differing in the details that matter: category assignments, blocking rules, banner timing, and the legal text versions visitors agreed to. Prefer the plugin's export and import, or a full database migration that carries its tables deliberately.
Consent records deserve explicit handling. The log of who consented to what, under which banner version, is legal evidence with retention value. Confirm before the old hosting is cancelled that the records exist, complete and readable, on the new host.
Test consent on staging like it is the launch
On the new environment, run the full test suite before go live: banner appears with correct text and choices, declining blocks analytics and marketing scripts, accepting enables them once, preference changes persist across pages, and region rules show the right variant.
Use a clean browser for each test so cached consent from the old site does not mask a broken banner. Also test with the migration's new caching and optimization plugins active, since script minification and delay features are frequent consent breakers that only appear in the production like configuration.
Keep the old environment until consent is verified live
After launch, repeat the core tests on the live domain, then keep the old hosting and its data untouched for a defined hold period. If a consent gap surfaces in the first weeks, the old configuration and records are the reference and the fallback.
Close the migration with a short written record: what was moved, what was tested, when, and any settings that could not be carried and were rebuilt. If the consent setup is ever questioned later, that note is the difference between a reconstructable history and a shrug.
Related reading
These earlier guides go deeper on connected questions: WordPress WooCommerce Stores and Cookie Consent: What Fires Before the Checkout Even Starts A WooCommerce store is a plugin stack with a shop attached. Payment, shipping, reviews, and marketing plugins each bring cookies and third party calls, and several fire on the first page view, long before checkout consent is considered., Cookieless Analytics on WordPress: When No Cookies Does Not Mean No Consent Questions Privacy focused analytics tools promise no cookies and no consent banner. Some deliver exactly that. Others collect device data, use fingerprinting, or run server side in ways that still count as processing personal data., and WordPress Real Estate Plugins and Cookie Consent: Listings, Maps, and Saved Searches Real estate plugins load maps, mortgage calculators, IDX feeds, and chat tools that track heavily. A consent pass for property sites, from listing pages to lead forms..
Frequently asked questions
Why do migrations break consent banners?
Consent setup is scattered: plugin database tables, blocking rules, custom CSS, region settings, and external tag manager configuration. Standard migration tools copy the site but miss or reset several of those pieces.
Should I reinstall the consent plugin on the new host?
No, migrate its settings and data deliberately, through export and import or a full database move. A fresh install silently returns to defaults and loses consent records.
What consent tests should run before launch?
Banner display and text, blocking on decline, single firing on accept, preference persistence, and correct region variants, all in clean browsers on the staging setup.
How long should old hosting be kept after a move?
Until consent behavior is verified live and for a defined hold period after, so the old configuration and consent records remain available as reference and fallback.