Migration
A form backend migration checklist, not a sales page
Moving a form to a different receiver looks like a one-line change: replace the action URL. In practice, the endpoint is the easiest part. The harder questions are what happens to delivery records, file uploads, autoresponses, and the forms you forgot were leaning on a feature only one receiver implements.
This checklist is receiver-neutral: it applies whether the thing answering the POST is a hosted form endpoint, a serverless function you deploy, or a form feature built into your host. Nothing below depends on which product you pick, including this one.
1. Does it accept the markup you already have?
Export one real form and compare field names. Repeated fields, nested bracket names, select values, checkboxes, and hidden fields are where “compatible” endpoints often diverge. Test a real payload, not a two-field demo.
2. Can you see delivery, not just acceptance?
A 200 response means the request was accepted. Ask what the product records after that: owner email, autoresponse, and webhook attempts should each have a status and an error. A failed send without a visible reason is an operational blind spot.
3. Is autoresponse included or gated?
An autoresponse confirms to the visitor that the message arrived. Some products reserve it for a higher tier. If it is part of your flow, check the plan that actually includes it rather than the headline price.
4. What are the file limits and the retention policy?
Check file count, size, allowed types, download access, and how long attachments are kept. “File uploads supported” is not enough: an expiring attachment or a public URL can change the risk profile of the form.
5. Are rules evaluated on the server?
Client-side validation improves the experience, but a script can bypass it. Require, block, spam, and route rules should run on the endpoint. Ask what happens when a rule fails: a clear error, a stored spam record, or a silent drop?
6. Are webhooks signed and retried?
If a submission creates a ticket or updates a CRM, the receiver needs a way to reject forged requests and a way to recover from downtime. Look for a signature header, a timestamp, documented retry behaviour, a delivery log, and replay.
7. Is the API included?
You may not need the API on day one, but you will want it when you reconcile a missed webhook or export a filtered list. Check whether the API is included in the plan you are considering and whether keys are self-service.
8. What is the exit path?
Can you export submissions as CSV? Can you delete a form and its files? Does the provider keep attachments after deletion? A backend should not make your own intake data difficult to retrieve.
9. How mature is the provider?
Operating history matters. A newer product may offer more features at a lower price but have less evidence behind its reliability. Ask for a status page, a published incident history, and an SLA if the form is business-critical.
10. What does the price include?
Compare the plan that includes the features you need, not the entry price. Add the cost of a higher tier for autoresponse, file storage, team seats, or integrations. A free early-access product is not a permanent price.
A practical comparison snapshot
| Criterion | Hand-rolled receiver | FreelyForm |
|---|---|---|
| Native HTML endpoint | You write it | Yes |
| Autoresponse | You write it | Every account |
| File uploads | You handle storage and cleanup | 5 × 25 MB default, 90-day retention |
| Partial submissions | You write it | Yes, with a resume link |
| Signed webhooks + replay | You write it | Yes, HMAC-SHA256 with a delivery log |
| Submission API | You write it | Included |
| Public status page / SLA | Yours to publish | Not yet |
| Running cost | Host, mail provider, your time | Free tier is 80 submissions a month |
The FreelyForm column describes implemented behaviour. The other column is what the same row costs when you own it.
A migration sequence that limits risk
- Create the destination form and verify every recipient.
- Duplicate the HTML exactly; change only the action URL.
- Send a normal entry, a missing-field entry, a file entry, and a spam-looking entry.
- Compare the stored payloads between the two receivers.
- Check owner email, autoresponse, and webhook records.
- Move one production form, keep the old endpoint for a release cycle, then continue.
When not to switch
Stay where you are if the current receiver already satisfies the operational requirements and the switch would only save money. Migration has a cost: retesting every form, re-verifying recipients, and re-checking integrations. A receiver with a published status page and a long incident history can be the rational choice even when a newer one has more features.
Switching questions
What is the most important thing to test before switching form backends?
Field compatibility and delivery visibility. Send the same payload to both endpoints, then compare what arrived, which channels were attempted, and what the failure states look like.
Can I migrate one form at a time?
Yes. Keep the old endpoint live and move a single low-risk form first. Compare the stored payload and delivery record before moving the forms that matter most.
Should price decide the switch?
Only after the operational requirements are met. A cheaper endpoint that hides failed deliveries or drops attachments is more expensive than the plan it replaced.