WPForms Prefill by URL uses keys built from the form ID, field ID, and optional subfield. Duplicating or rebuilding a form can change those identifiers while ads, emails, QR codes, partner links, redirects, JavaScript, CRM mappings, and documentation continue to send the old keys. The visible form may still submit, which hides the fact that routing, conditional logic, hidden attribution, or choice values no longer populate. A migration map keeps old and new contracts explicit and gives each external link an owner.
Use this before replacing a live WPForms form, duplicating it for a campaign or language, changing composite fields, or moving traffic from an old form ID to a new one.
Quick answer
Export the old and new form structures and map every old form ID, field ID, subfield, stored choice value, conditional rule, hidden field, notification, webhook, and CRM destination to its replacement. Inventory every URL producer, including ads, email templates, QR codes, partner pages, redirects, JavaScript, and internal links. Create valid, missing, stale, encoded, and tampered fixtures. Update producers in a controlled window, keep a measured compatibility redirect or friendly-key mapper only when needed, and verify the final URL, visible branch, entry, notification, webhook, CRM, and analytics event.
Test scenarios to run
Run the same controlled fixture across these branches. Write down the expected result before testing so a surprising response is easy to identify.
| Scenario | Fixture | Expected result |
|---|
| New URL | New form and field IDs | Correct value and branch |
| Old URL during migration | Documented compatibility map | Safe mapped value or clear fallback |
| Unknown old key | No approved mapping | Ignored without stale value |
| Dynamic choice | Current stored value | Entry and CRM agree |
Diagnostic table
Use this table to connect the observed behavior to evidence and a verification step.
| Action | Evidence | Verification |
|---|
| Export old and new schemas | Export both form definitions and record form IDs, field IDs, field types, composite subfields, labels, stored values, dynamic choices, hidden fields, and conditional rules. | Every old key has an owner, new key, behavior, and removal date. |
| Inventory every URL producer | Search campaign managers, email tools, QR destinations, partner pages, redirects, templates, scripts, content, and documentation for old wpf-based keys. | The final URL retains the intended encoded query after redirects and caches. |
| Build the ID migration map | Create a migration table with old key, new key, accepted value, owner, traffic source, update date, compatibility behavior, and removal date. | Visible fields, logic, entries, notifications, webhooks, CRM, and analytics agree. |
| Update and test links in a controlled window | Test old and new links through every redirect and cache layer on mobile and desktop, with AJAX and non-AJAX submissions. | Expired mappings are removed without breaking active campaign links. |
What to check first
- Export both form definitions and record form IDs, field IDs, field types, composite subfields, labels, stored values, dynamic choices, hidden fields, and conditional rules.
- Search campaign managers, email tools, QR destinations, partner pages, redirects, templates, scripts, content, and documentation for old wpf-based keys.
- Create a migration table with old key, new key, accepted value, owner, traffic source, update date, compatibility behavior, and removal date.
- Test old and new links through every redirect and cache layer on mobile and desktop, with AJAX and non-AJAX submissions.
- Compare rendered fields, conditional branch, entry, notification, confirmation, webhook, CRM, and analytics using one fixture ID.
Field notes
- Write the expected result before changing anything and keep one repeatable canary fixture for the full test window.
- Record exact versions and UTC timestamps because caches, retries, scheduled actions, and deployments can change the evidence between checks.
- Test the public browser path and the stored server-side result, not only an admin preview or isolated API response.
- Close the task only after the visible workflow, logs, stored record, and relevant downstream system agree.
Useful command or data shape
Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.
old_form,old_key,new_form,new_key,value,owner,remove_after
20,wpf20_4,37,wpf37_6,sales,paid-search,2026-10-01
20,wpf20_7_city,37,wpf37_9_city,chicago,email,2026-10-01
# Keep only approved compatibility mappings with a removal date.
Why this usually happens
- Campaign URLs are treated as marketing copy instead of a versioned interface to form IDs.
- Labels appear unchanged while stored choice values or subfields differ in the duplicate.
- A redirect preserves the page path but drops or rewrites the prefill query string.
- The visible field is checked without comparing entry and downstream routing.
Decision rule
Do not retire the old form contract until every owned URL producer is updated or has a measured compatibility path and the new entry-to-CRM workflow passes.
Production verification checklist
- Every old key has an owner, new key, behavior, and removal date.
- The final URL retains the intended encoded query after redirects and caches.
- Visible fields, logic, entries, notifications, webhooks, CRM, and analytics agree.
- Expired mappings are removed without breaking active campaign links.
Safe fix order
Use a sequence that makes each result easy to prove. Stop when new evidence changes the scope or owner of the problem.
- Export old and new schemas
- Inventory every URL producer
- Build the ID migration map
- Update and test links in a controlled window
- Remove expired compatibility rules
Mistakes to avoid
- Changing production before recording the exact version, request, UTC time, fixture, and rollback point.
- Treating one successful browser view as proof while logs, stored records, background jobs, and downstream systems remain unchecked.
- Testing a different role, cache state, locale, form, order, device, or integration path from the one users actually reach.
- Leaving debug output, temporary exclusions, test accounts, broad permissions, or helper code active after the verification window.
Questions teams ask during testing
Should I test this directly in production?
Start with read-only evidence and reproduce on staging when the change affects code, security, checkout, forms, indexing, or permissions. If production is required, use one named canary, a short monitored window, and a tested rollback.
How do I avoid a false positive?
Repeat the same fixture with the same versions, URL, role, locale, cache state, and downstream integration. Compare stored evidence and logs instead of relying on a visual impression.
What evidence should I keep?
Keep UTC time, exact versions, URL or record ID, expected result, actual result, relevant log lines, change made, rollback point, owner, and final verification. Redact credentials and personal data.
When should I escalate?
Escalate when the site is unavailable, security scope is unclear, checkout or lead capture is affected, several systems disagree, or the next action could destroy evidence.
What to tell the client or owner
Give the owner a concise evidence packet with the affected workflow, exact versions, UTC test time, fixture ID, expected result, actual result, key logs, change made, rollback point, final result, owner, and next review date. Remove credentials and personal data before sharing it.
When HandL WP should help
Bring in help when this affects leads, checkout, search visibility, security, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.
If this is active on a production site, have HandL WP migrate the WPForms URL contract.
Related HandL WP guides
Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.
Helpful references