The short version
- A form that posts nowhere renders exactly like one that works. The failure sits on the far side of the submit button, where nobody looks.
- During a rebuild, stub the form visibly or take the page down. A live-looking form on a half-migrated page collects nothing and says so to nobody.
- The only proof a form works is a record at the destination with a timestamp on it.
- Inventory every form before the migration: URL, destination, hidden fields, notification recipient, normal volume. That list is what you verify against after launch.
A form that posts nowhere renders exactly like a form that works. On a 42-route rebuild we kept the old version of several pages reachable behind a staging path, and we pulled the forms out of those pages before anybody could get to them. The alternative was a page that looked live, with a submit button wired to an endpoint the new build had already removed.
Why does a broken form look exactly like a working one?
Because the failure happens on the far side of the submit button. The field validation runs. The button changes state and a thank-you message appears where the form was. All of that is front-end behaviour and it survives the destination being gone.
The only evidence that a form works is a record at the other end with a timestamp on it.
Where a migrated form fails, and what anybody watching would see:
| Failure point | What the visitor sees | What reaches the CRM | How it surfaces |
|---|---|---|---|
| Endpoint removed in the rebuild | Success message | Nothing | A salesperson asks why inbound went quiet |
| Form rebuilt with a new ID | Success message | Nothing | The same way, weeks later |
| Hidden fields dropped | Success message | A record with no source or consent | Reporting stops attributing anything |
| Old page still indexed | The pre-rebuild page | Whatever the old endpoint does | Search traffic keeps arriving at it |
What does stubbing a form loudly mean?
Take the form out and leave a sentence where it stood, saying the page is being rebuilt, with one route beside it that works. On the staged pages we kept during that rebuild there were no fields left to fill in at all. Somebody who wanted to reach a human got a live page to go to instead of a button with nothing behind it.
Redirecting the page or taking it down is better again. A page that cannot capture a lead and cannot serve the visitor has no reason to stay reachable through a migration.
How do you test a form so the test proves something?
Submit a real entry carrying a marker you can search for, then open the destination system and find that record.
Then check the rest of the trip. The record has to reach the CRM, and off the back of it a notification has to fire and land with somebody who still works there. Each of those hops fails on its own, and none of them are visible from a browser.
Which forms should exist during a rebuild?
The ones somebody pushed a test through that week and found at the other end. While that rebuild ran, the site carried fewer working forms than it had before it started, which was the intention rather than an accident of scheduling.
Build the inventory before the migration starts: the URL each form lives on, where the submission goes, which hidden fields it carries, who gets notified, what a normal week of volume looks like. That list is the checklist you verify against on launch day.
Half-migrated forms drop leads silently. Stub them loudly or take the page down.
How do you know it is still working next month?
Set a floor on weekly volume and alert when submissions drop under it. Errors are the wrong trigger. We ran a lead sync out of an ad platform into Slack and on into an email tool, and it broke every time somebody swapped the form behind it without producing a single error anywhere in the chain. Zero volume was the only thing that ever gave it away.
Then submit a real test on a schedule. Monthly at minimum, and again whenever the page, the form tool or the CRM changes underneath it. The alternative is hearing about it from the person whose number depends on those submissions.
The neighbouring checks worth running in the same week are verifying what is actually live and watching for integrations that fail silently.
Frequently asked questions
Why do website forms stop working after a migration?
Because the destination changes while the front end stays the same. An endpoint is removed, a form is rebuilt with a new identifier, or the hidden fields carrying source and consent are dropped. The page still validates input and shows a success message, so the failure is invisible from the browser.
How do you test whether a form is actually submitting?
Submit a real entry containing a marker you can search for, then find that record at the destination system. Confirm the notification reached a person who still works there. A thank-you page proves only that the front end ran.
What should you do with forms on pages you have not migrated yet?
Remove the form and replace it with a visible line saying the page is being rebuilt, plus one route that works. If the page has no other purpose, redirect it or take it down. A live-looking form on a half-migrated page collects nothing and tells nobody.
How long can a broken form go unnoticed?
For as long as nobody counts submissions at the destination, because a dead form and a quiet week produce the same chart. It tends to surface when somebody in sales asks why inbound went quiet, which is after the leads have already been lost. Nothing the visitor sees will raise it sooner.
Who should own form testing after a launch?
One named person, usually whoever owns the destination system, because they are the one who notices missing records. Shared ownership produces the case where the web team and the CRM team each assume the other checked.
What belongs in a form inventory?
For every form: the URL it sits on, the destination system, the hidden fields it carries such as source and consent, the notification recipient, and normal weekly volume. That last item is what makes an alert possible.
Sources
- Chua Network delivery data across 8 client accounts (internal fact bank)
- Chua Network engagement records, anonymized (internal experience bank)
