A contact form has serious vendor lock-in risk when you cannot export complete submissions, reproduce the form outside the provider, or move delivery and integrations without losing evidence or accessibility. Check data export, attachment retrieval, standards-based markup, API or webhook access, sender-domain control, account ownership, and a documented migration path before depending on the form.
Check whether the submissions are truly portable
Ask for a sample export before signing a long contract or building years of history. It should include field names, values, timestamps, consent evidence where collected, routing status, attachment references, spam or moderation state, and stable identifiers. Confirm the format is documented and usable without the vendor's application. A dashboard view or printable report is not the same as a complete export.
Test deletion and retention controls as well as export. Record who owns the account, who can authorize an export, how long it takes, whether attachments are included, and what happens after cancellation. If the only administrator belongs to an outside developer or former employee, the business already has an ownership problem even if the software is technically portable.
Inspect the form implementation
A portable form should preserve the user-facing requirements even when the back end changes. W3C guidance says forms should identify controls with labels, group related controls, provide instructions, validate input, and notify users of errors or successful completion. See the W3C Forms Tutorial and Labeling Controls. Ask whether those semantics live in ordinary page markup or depend entirely on an opaque widget that cannot be inspected or replaced.
Third-party scripts add a separate dependency. OWASP identifies loss of control over changes, arbitrary code execution, and disclosure of information as major risks of third-party JavaScript. Its Third Party JavaScript Management guidance recommends controls such as monitoring vendor changes, secure transport, subresource integrity where applicable, containment, and reviewing vendor security practices. A form that breaks when the provider changes a remote script has operational lock-in as well as migration lock-in.
Check delivery and integration exits
List every destination: email, database, CRM, ticketing system, spreadsheet, analytics service, and automation. Ask whether the vendor supports documented webhooks or APIs, how retries and failures are exposed, and whether event history can be exported. Verify that the organization controls its sending domain, reply address, DNS records, and receiving mailbox rather than borrowing an identity that disappears with the vendor.
Pricing can create lock-in even when export exists. Note fees for API access, bulk export, attachment retrieval, additional administrators, increased retention, or cancellation assistance. A short export window or an undocumented rate limit can make a nominal exit impractical.
Run a migration rehearsal
Create a small representative form, submit ordinary and error cases, export the data, rebuild the form in a neutral test environment, and verify labels, validation, delivery, attachments, consent evidence, and confirmation behavior. Time the process and document what required vendor support.
Classify each issue as acceptable, contractually correctable, technically mitigated, or a stop condition. The clearest warning sign is not the presence of a vendor; it is the absence of a tested way to keep serving users and retain records when that vendor is unavailable or replaced.
Sources
- Forms Tutorial — World Wide Web Consortium Web Accessibility Initiative
- Labeling Controls — W3C Web Accessibility Initiative
- Third Party JavaScript Management Cheat Sheet — OWASP Foundation