Migrating Forms and Lead Capture Without Losing Leads

How do you migrate website forms without losing leads?

You migrate website forms by treating each one as a small integration, not a design element: inventory it, rebuild it with the same data, map it to the CRM and prove it works with a real submission. A form that looks right and sends nothing is the most expensive bug a migration can ship.

Forms break quietly. The page renders, the button works, the visitor sees a thank-you message, and the lead never reaches sales. Nobody notices until someone asks why demo requests dropped. That's why form migration deserves its own checklist inside the wider CMS content migration plan.

This checklist covers the four places leads get lost: forms nobody listed, hidden data that stops being captured, fields mapped to the wrong CRM property, and launch-day issues that only show up on the live domain.

What should you inventory before you migrate forms?

Inventory every form on the old site with its fields, hidden fields, destination, notifications and owner. Crawl the site rather than relying on memory, because forms hide in footers, popups, gated downloads and old landing pages.

Also note any form that triggers something downstream, such as a sales routing rule or a nurture sequence keyed to a form name. Renaming the form can quietly break those automations.

How do you keep hidden fields and UTM tracking working?

Rebuild every hidden field on the new form and re-add the script that fills it, then confirm the values arrive in the CRM. Hidden fields are where attribution lives, and they're invisible to anyone checking the page by eye.

• UTM parameters. If the old site captured utm_source, utm_medium and utm_campaign into hidden fields, the new site needs the same capture script, ideally storing values so they survive a visitor browsing to a second page.
• Page and referrer. Many teams record the page a form was submitted from. New URLs mean new values, so update any CRM reports that filter on old paths.
• Click IDs. Ad click identifiers used for offline conversion imports need their own hidden fields.
• CRM tracking cookies. HubSpot links submissions to a visitor's history through its tracking cookie. Embedded HubSpot forms handle this; custom forms that post to HubSpot's API must pass it explicitly.

For the analytics side of the same problem, see our guide to conversion tracking for lead-gen websites.

How do you map form fields to your CRM?

Map each form field to a CRM property by its internal name, check that the field types match, and test each mapping with a submission. Labels can change freely; internal names and types can't.

A dropdown on the website must send values the CRM property accepts, exactly, including case. A free-text country field mapped to a CRM dropdown property will fail or create junk values. Phone and email validation should match what the CRM expects, or records get rejected without an error the visitor ever sees.

HubSpot forms migration is its own case. If you're leaving HubSpot CMS but keeping the CRM, you can embed HubSpot forms on the new site, which keeps tracking and workflows intact. Our guides to HubSpot to Webflow and Webflow to HubSpot cover both directions.

Which form setup should you use on the new platform?

Embed your CRM's forms when attribution and workflows matter most, use the platform's native forms when you need full design control, and build a custom handler when you need both. Each trades design freedom against setup work.

Moving from code to a visual builder changes this choice too: forms handled by server code need a new home. Our guide to moving from code to a visual builder covers what replaces them.

The form migration checklist for launch day

Run this list on the live domain, not on staging, because domains, cookies and spam settings behave differently in production.

1. Every form from the inventory exists on the new site, on the right page.
2. Each visible field matches the old form, including required fields and validation.
3. Each hidden field is present and fills correctly, including UTMs from a tagged test link.
4. A test submission from every form reaches the CRM with every property filled.
5. Notification emails arrive in the right inboxes and aren't in spam.
6. Thank-you pages, redirects and auto-responders work.
7. CRM workflows triggered by the old form names still fire.
8. Spam protection is on, and a normal submission still passes it.
9. Analytics records the form submission as a key event.

How do you test form submissions end to end?

Submit each form with recognizable test data, then trace the record through every system it should touch: CRM, notifications, workflows and analytics. A test passes only when the lead arrives where sales will see it.

1. 1

   Use a tagged link

   Open the page through a URL with test UTM values, so you can check attribution as well as the form.

2. 2

   Submit with labelled data

   Use a name like Migration Test plus the form name, and an inbox you control.

3. 3

   Find the record

   Search the CRM for the test contact and check every property, including hidden fields and source.

4. 4

   Check side effects

   Confirm the notification email, any auto-responder and any workflow enrollment.

5. 5

   Clean up

   Delete or tag test records so they don't distort reports.

If notifications go missing, the problem is often email authentication rather than the form; our guide to SPF, DKIM and DMARC for website forms covers the fixes.