Every WordPress site I migrate to Astro has the same hidden landmine. It's not the theme, it's not the blog posts. It's the forms.
Contact Form 7, Gravity Forms, WPForms, sometimes all three on one site because three different devs touched it over the years. The client doesn't think about any of it. They just know leads show up in their inbox. If that stops the day you launch, you hear about it in about two weeks when they ask why the phone went quiet.
So here's the checklist I run now before I touch DNS.
1. Find every form, not just the contact page
I don't trust the menu. I search the database export for shortcodes and blocks:
grep -oE '\[(contact-form-7|gravityform|wpforms)[^]]*\]' wp-export.xml | sort | uniq -c
grep -o 'wp:gravityforms/form[^>]*' wp-export.xml | sort | uniq -c
That usually turns up the forgotten ones. A quote form on a landing page from 2021. A newsletter box in the footer widget. A "request a callback" popup nobody remembers adding.
I put each one in a little table: page URL, form name, fields, where it sends, and anything weird it does.
2. Figure out what each form actually does
This is the part people skip. A form plugin is rarely "just email me". Look for:
- Multiple recipients or routing (sales vs support based on a dropdown)
- Integrations like Mailchimp, a CRM, Zapier, Google Sheets
- File uploads (CVs on a careers page, photos for a quote)
- Conditional fields
- Auto replies to the person who submitted
- Thank you page redirects that the client's Google Ads conversion tracking depends on
That last one has bitten me. The old site sent people to /thank-you/ and an ads conversion fired there. New site showed an inline "thanks!" message and conversions dropped to zero. Client thought the ads broke.
3. Rebuild as plain HTML
On the Astro side I keep forms boring. A normal <form> with real name attributes, no JS required to submit. I host the client sites on novence.ai so I create the form there (CLI, API or I just ask the coding agent to do it over MCP) and point the action at it:
<form action="/__forms/FORM_ID" method="POST">
<label>Name <input name="name" required></label>
<label>Email <input type="email" name="email" required></label>
<label>Message <textarea name="message" required></textarea></label>
<!-- honeypot, keep it hidden -->
<input type="text" name="_gotcha" tabindex="-1" autocomplete="off" style="display:none">
<button type="submit">Send</button>
</form>
Submissions get stored and emailed, which covers maybe 80% of what the old plugins were doing. The honeypot plus rate limiting has been enough spam control for the small business sites I do. If you're somewhere else, Formspree or Web3Forms work the same way, the pattern is identical.
For the other 20%:
- File uploads: I don't fake these. Most form backends for static sites won't take files and honestly I'd rather not store CVs anyway. I link to a proper upload tool or ask them to email attachments.
- CRM / Mailchimp: their own embed form, or a webhook into Zapier. Don't try to rebuild the integration in client side JS.
- Routing by dropdown: two separate forms is often simpler than one smart one. Ask the client if anyone actually uses the dropdown. Half the time nobody does.
4. Keep the thank you URL
If the old site redirected to a thank you page, I build the same page at the same path. Zero clever-ness. Then tracking keeps working and I don't have to explain to an ads person why the numbers moved.
If the old thank you URL had a weird slug I still keep it, and if I really have to change it, it goes in /_redirects with everything else.
5. Test from the preview URL before launch
Before the domain moves I submit every form on the preview deploy with a real email address:
- did it arrive, and how fast
- can the client see the visitor email clearly so they can reply fast
- does the honeypot actually stay hidden on mobile
- does the thank you page load
I also ask the coding agent to run the checks (lighthouse, axe, broken links) so labels on inputs don't get missed. Accessibility on forms is where AI generated markup is most sloppy in my experiance, usually placeholder text pretending to be a label.
6. Tell the client where leads go now
One short email. "Your enquiries now come from this address, add it to your contacts so it doesn't land in spam." That one sentance has saved me more support tickets than anything else on this list.
And I leave the old WordPress install up for a week after launch with its forms still pointing at the old inbox, just in case some cached page or old ad sends someone there.
Forms are boring, which is exactly why they break quietly. Do the audit first and the actual rebuild takes like twenty minutes per site.
What weird form setups have you found on old WP sites? I once found one that emailed a guy who left the company in 2019.
Top comments (1)
The thank-you page point is the one I would add to every migration checklist. A form can work perfectly and still break reporting if that redirect changes. Auditing where each form sends leads before DNS moves is worth the extra hour.