A migration can preserve every important URL while breaking the path that turns a visitor into a handled inquiry. Forms, tracking and consent settings cross several systems, so a successful page load is only the start of launch verification.
TLDR: Inventory the old form and measurement paths, map them to the new site and test before-and-after behavior with approved synthetic data. Review consent and script handling with the appropriate specialists. Keep redirects, lead capture and analytics as separate acceptance checks.
Map the assets that do not appear in a redirect sheet
We recommend recording each form, booking tool, CTA, confirmation destination, notification, integration and tracking dependency. Include asset IDs and the pages where each appears.
For each old asset, decide whether the migration retains it, replaces it or retires it. Document the reason and the new destination. A reused form and a new form with the same visible fields can have different downstream settings.
The landing-page guide describes the visitor-facing path. Your migration map also needs the record and owner that receive the inquiry.
Verify tracking without duplicating it
As checked on September 7, 2026, HubSpot documents that its tracking code supports measurement on external pages; the tracking code itself does not create or install forms. Confirm how tracking is installed on the old and new environments rather than assuming a form embed covers everything. HubSpot tracking-code documentation
We recommend checking for existing native integrations, tag-manager containers and custom snippets before adding anything. Record which implementation owns each event and avoid installing a second version just because a familiar script is not visible in one editor field.
Keep the test environment from contaminating production reports where your approved measurement setup allows it. Document any exclusions and verify that they do not unintentionally exclude the live site.
Use a before-and-after test matrix
The matrix below is a synthetic test plan, not evidence that a migration has passed. Expected behavior must be approved for the actual site.
| Test | Before-migration evidence | After-migration acceptance |
|---|---|---|
| Valid inquiry | Approved form fields and confirmation behavior | The new path captures the intended data and shows the approved next step. |
| Invalid or incomplete entry | Existing validation and error handling | Required errors are readable and do not discard useful input unexpectedly. |
| Internal handoff | Record, owner and notification behavior | The inquiry reaches the agreed owner without unintended duplication. |
| Declined optional cookies | Documented consent and script behavior | The reviewed preferences produce the intended behavior on the new site. |
| Accepted optional cookies | Documented measurement behavior | Intended events appear once under the approved conditions. |
| Repeat visit | Existing preference and identity behavior | The new setup behaves as designed without assuming every visitor is identifiable. |
Retain the test input, date, environment and reviewer. Do not put real contact data into a public launch checklist.
Review consent as a configuration and policy question
HubSpot documents different consent-banner types and conditions for its Google Consent Mode integration. Native support depends on the site, banner and analytics integration setup; custom or external configurations can require manual implementation. HubSpot consent-banner types, HubSpot Google Consent Mode guidance
We recommend having the appropriate privacy owner and developer review the migration's actual scripts, regions and choices. Do not infer that every third-party script follows a banner merely because the banner is visible. This is implementation guidance, not legal advice or a compliance certification.
Test the approved behavior, including refusal and changed preferences where supported. Keep unresolved policy questions as launch decisions for the authorized reviewer.
Assign migration test failures an owner and recovery plan
We recommend distinguishing page defects, form configuration, routing logic and measurement issues. A developer may fix a layout problem while an administrator must resolve the wrong owner or notification.
Do not assume page version history restores form configuration. HubSpot's forms FAQ states that forms cannot be reverted to a previous version through that feature. Preserve the configuration evidence needed to recreate approved behavior. HubSpot forms FAQ
Before launch, agree on which defects block release and who can authorize a rollback or targeted fix. Retest the affected path after any correction.
Build a HubSpot migration checklist for the inquiry path
This HubSpot migration checklist covers forms, tracking and consent continuity on a website move. It is separate from a CRM data migration that imports historical contacts, companies or deals.
Keep both workstreams coordinated when they occur together. A successful import count does not prove the new website captures inquiries correctly, and a working form does not prove historical data migrated accurately.
Record the source system and destination for each value
Identify the submitted field and the corresponding HubSpot property where that value should appear. Preserve the intended data type and handling of missing or unusual inputs.
If a new form changes the property mapping, document the decision. A field label can remain familiar while the stored value changes meaning.
Use a controlled test to check the actual record result. Do not infer correct mapping from a form preview.
Inspect identity and duplicate handling
An inquiry from an existing contact may need different observation from an inquiry using a new synthetic identity. Include both where the approved test plan permits.
Check whether the expected record is updated or created, and retain its identifier. Do not call every submission a new contact.
If the migration changes the form or integration method, verify the intended identity behavior rather than assume the old site's rules still apply. Keep unexpected duplicate records as findings for the appropriate owner.
Preserve downstream automation deliberately
Inventory notifications, owner assignment, lifecycle updates and any expected ticket creation or follow-up tied to the form. Name the configuration responsible for each action.
Review the production effects before submitting test data. A migration test should not accidentally start an email campaign or send an unsupported customer message.
Keep the observed form result and downstream result separate. One can pass while the other fails.
Coordinate the consent and measurement review
The approved privacy arrangement determines which collection behavior the implementation should support. The technical test checks the selected configuration against that arrangement.
Record the banner, integrations, script ownership and relevant regions. Do not infer legal compliance from a visible consent control or a plugin's marketing description.
Test refusal as well as acceptance
The test plan should describe what is expected when optional choices are declined, accepted or changed where supported. Observe the actual script and event behavior.
A page that loads normally after refusal may still need investigation of its third-party scripts. Conversely, a missing analytics event can be consistent with the approved preference rather than a broken migration.
Keep the expected behavior with the result so the launch team can distinguish those cases.
Check the final domain separately from staging
The public domain may use a different tag-manager environment, integration setting or consent configuration. Repeat the relevant checks after the authorized cutover.
A passing staged page does not establish final tracking behavior. Record the actual live URL, environment, timestamp and observed event where the approved setup exposes it.
Do not change production settings repeatedly to make one test appear. Diagnose the implementation responsible for the mismatch first.
Retain a recovery packet
Preserve the old and new asset identifiers, configuration evidence, mappings and test results. Identify which parts can be restored and which must be recreated through a separate process.
Assign clear ownership for page code, forms, CRM routing and measurement. A single “website rollback” label can hide several different recovery tasks.
Define the release blockers
We recommend blocking release for an inaccessible required form, incorrect sensitive-data handling, an inquiry sent to the wrong destination or a broken promised delivery path until the responsible owner resolves or explicitly accepts the issue.
Other findings may be scheduled as follow-up work if their impact and acceptance are clear. Keep that decision documented.
Verify the repair before closing the finding
Rerun the affected path with the approved input and inspect both the visitor result and stored record. Preserve the earlier failure and the configuration that passed.
A submitted command or saved setting is an intermediate step. The migration record should show the observed behavior that closes the issue.
Close the migration with observed evidence
Verify the actual live pages after the approved launch. A passing preview does not establish that the public domain, scripts and integrations behave identically. Record the final results without treating an intermediate save as completion.
For platform context, review the WordPress and HubSpot CMS comparison. For help with migration acceptance, explore website design services or request a scoped review.
