Migrate from Jotform to Formbricks

Migrate from Jotform to Formbricks: what moves cleanly and what needs rebuilding

The migration is a rebuild of forms and logic, with a separate data export and replacement tools for payments and PDFs. Formbricks does not copy Jotform forms across, so each live form has to be recreated as a Formbricks survey, tested, and then pointed at from the website. Past submissions and uploaded files are a separate workstream with their own export and storage decisions. Teams usually take this on with their internal IT or platform engineering staff, sometimes with an implementation partner for the hosting, integrations and cutover. The effort scales with the number of active forms and how much conditional logic and hidden field logic each one carries, not with the number of past responses. The main risk is silent breakage rather than visible failure. A form can look correct in preview while a branch, a hidden field value passed from a URL, or a calculated field behaves differently in production, and a respondent may never report it. Before any cutover, inventory every Jotform form with its owner, its traffic, its logic rules and its integrations, then decide for each one whether it is retired, rebuilt, or kept on Jotform until its replacement is verified. Confirm with Formbricks which question types, hidden field handling and file upload limits match your forms, and check the current behavior in the Formbricks GitHub repository before you commit to a design.

Plan the non-form pieces separately, because Formbricks is a survey and feedback tool rather than a payment, document or app-building product. Payment steps need a payment provider integration you run or contract directly, and any PDF generated from a submission needs a document step in a workflow tool, such as a self-hosted automation platform fed by Formbricks webhooks. Ask whether each Jotform payment or PDF flow has a tested replacement before you retire the original form. Your team should also list every website embed, email link and QR code that points at a Jotform URL, since swapping those embeds is often the last step and the easiest to forget. Keep the old forms running, with submissions still being collected, until each new embed has been tested on the live site. For past submissions, export the Jotform data in the formats it offers, store it in a system your records policy covers, and map field names to the new survey so that analysis still works after the cutover. Uploaded files need their own plan, since they are stored apart from the response rows and must be downloaded, checked for completeness and kept under the same retention rules. Ask your Jotform account team and your Formbricks administrator to confirm export formats, file limits and retention settings for your plan and version before you start, and keep a dated record of the export checks for your auditors.

Which Jotform capabilities map to Formbricks, and which need rework

This table compares the Jotform features most migrations touch with their Formbricks equivalents. Read "clean" as a direct move, "needs rework" as a rebuild with the same intent, and "gap" as a capability to replace with another tool. Confirm each row against the Formbricks version you plan to run, because the feature set changes between releases.

Jotform capability	Formbricks equivalent	Status
Form building and question types	Survey editor for link, website, app and email surveys	Needs rework
Conditional logic	Advanced logic is included in the Community Edition; rebuild each branch and test it	Needs rework
Hidden fields	Hidden fields are passed through URL parameters or the embed; map each one before cutover	Needs rework
Multi-language forms	Multi-language surveys and UI are included in the Community Edition	Clean
File upload questions	File upload is included; existing Jotform files must be downloaded and stored separately	Needs rework
Webhooks and API	Webhooks and full API access are included in the Community Edition	Clean
Website embeds and link sharing	Website and link surveys replace embed codes; update every page that loads the Jotform script	Needs rework
Payment forms and collection	No payment collection; keep a separate payment processor and connect it through a webhook	Gap
PDF generation and document output	No document engine; generate PDFs in a separate tool from exported responses	Gap
App building and form-based apps	Formbricks is a survey and feedback tool; replace app features with a workflow or application platform	Gap

Which data and integrations move, and through which export paths

A Jotform migration moves five kinds of material: form definitions, past submissions, uploaded files, respondent metadata and the connected tools that consume responses. Each one has its own export path, and the paths differ in how much they carry and how much manual work they need. Confirm each path against the Jotform account in use before you plan the cutover.

Form definitions and logic

Formbricks does not import Jotform form files, so each form is rebuilt as a Formbricks survey. Export or screenshot each form's questions, branching rules, hidden fields and calculated values from Jotform before you start. Use the export as a specification, not as an import source. Check which question types have no direct Formbricks equivalent, such as payment, signature or PDF-linked fields, and record a decision for each one.

Past submissions

Export past Jotform submissions from the account as spreadsheet or JSON files and keep them as an archive that sits beside the new survey data. Formbricks stores new responses from launch onward, so historical submissions are usually not re-imported as responses. Confirm the export format, whether it includes deleted or partial submissions, and whether the export is limited by date range or form.

Uploaded files

Files uploaded through Jotform forms are stored in Jotform's servers, and their links may stop working once the account changes. Download attachments in bulk where the account allows it, store them in your own file store, and map each file to its submission ID. Formbricks supports file upload questions in the Community Edition, so confirm where new uploads are stored in your self-hosted deployment before collecting personal data.

Respondent metadata

Submission timestamps, IP-derived fields, referrer data and user-agent details are often part of a Jotform export but may not map to Formbricks fields one to one. Decide which metadata you keep, which you drop for privacy reasons, and how you label it in the archive. Document the retention period for each field because it becomes your responsibility on your own servers.

Connected tools through webhooks and the API

Formbricks offers webhooks and full API access in the Community Edition, and it integrates with Slack, Notion, Zapier and n8n. Rebuild each Jotform integration as a Formbricks webhook or API call, then test it with a sample response. Jotform connectors that you used through a vendor app may not have an equivalent, so list each one and confirm its replacement before turning off the old flow.

Embedded code on web pages

Jotform embed code on your websites is replaced, not migrated. Each embed snippet points to a Jotform-hosted form, so it must be swapped for a Formbricks website, link or email survey once the new survey is live. Keep the old Jotform form active until every page is updated and checked, and track which pages carry the old code so none are missed.

The migration sequence from inventory to decommission

This sequence moves Jotform forms to self-hosted Formbricks in controlled stages, so each form is proven before the old system is switched off. Each step ends with a written artifact that the next step depends on.

Build the form register
List every Jotform form that is still live, including forms that are embedded on websites, shared as links, or connected to payments, PDF generation or other apps. For each form, record its owner, its public URL or embed location, its submission volume over a period you choose, its conditional logic, hidden fields, file uploads and any connected integrations. Ask each owner to confirm whether the form is still needed. The output is a signed-off form register, and a form is only in scope for migration once it appears on that register.
Classify forms by what they do
Sort the register into three groups: forms Formbricks can take over directly, forms that depend on Jotform payment, PDF or app-building features, and forms that should be retired. Formbricks is a survey and feedback tool, so forms that collect payments or generate documents need a separate tool chosen in advance. Note which forms collect personal or regulated data, because those need a decision on hosting and access before any build starts. The output is a classified register with a named replacement tool for every dependent feature.
Run a pilot on self-hosted Formbricks
Deploy a self-hosted Formbricks instance inside your own infrastructure and rebuild one low-risk form from the register, chosen because it uses conditional logic, hidden fields and a file upload. Test it on the devices and browsers your respondents use, and check that the hidden field values arrive in the stored response and in any webhook payload. Confirm the file upload stores files where your data handling rules require. Ask the Formbricks team or DeployOpen to confirm any feature that the pilot does not cover. The output is a pilot sign-off record that names the form, the tester and the open issues.
Rebuild the remaining forms in waves
Rebuild the remaining direct-migration forms in batches, starting with the forms that have the fewest dependencies. Recreate logic branches and hidden fields one by one, then compare the rebuilt form against the Jotform original using the same test answers. Keep a change log for each form that records any behavior difference and the decision taken. The output is a set of rebuilt forms, each with a test record that shows the answers produce the same routing and stored values as the original.
Run both systems in parallel
Keep the Jotform form live while the Formbricks version collects responses in parallel for a period agreed with each form owner. Compare response counts and sample records from both systems each week, looking for missing answers, duplicated submissions or differences in hidden field values. Note that Jotform's own export or API timing may lag recent submissions, so reconcile by a cutoff time rather than assuming the last record is complete. The output is a parallel-run reconciliation log that shows no unexplained gaps before cutover is approved.
Cut over embeds and links
Replace each Jotform embed code, shared link and QR code with the Formbricks equivalent, then freeze the Jotform form so it no longer accepts new submissions. Check the live pages on the sites where the embed appears, including mobile layouts and any content security policy that blocks third-party frames. Update any notification emails, bookmarks or internal documents that point to the old form. The output is a cutover record listing every changed location and a confirmed test submission from each one.
Verify exports before decommissioning
Export all past Jotform submissions and uploaded files, and store them in the archive location your retention policy requires. Check the export against the Jotform record count for each form and spot-check uploaded files by opening them. Confirm that you can search and read the archive without Jotform access. Only after this check should you cancel the Jotform plan or delete the account, because a deleted account may not give you a second chance to export. The output is an archived export set with a count and checksum record for each form, signed off by the data owner.

How to run Jotform and Formbricks in parallel without losing responses

The core principle of a parallel run is that each form has exactly one place where new responses land at any moment. Before anything is rebuilt, record for every live Jotform form which URL or embed it uses, who receives its notification emails, and which integrations (spreadsheets, CRM connectors, webhooks) consume its submissions. Then pick a cutover date per form, not one date for the whole account. Until that date, Jotform remains the sole collector. After it, the Formbricks survey takes the public link or embed, and the Jotform form is set to closed or pointed at a holding message, so that no respondent is split between two systems. Keep a simple register with form name, old URL, new URL, cutover date and owner. Reconciling counts depends on it.

Reconciliation is where responses go missing. A Jotform export captures submissions up to the moment it runs, so any response that arrives during or after the export is absent from the file. Plan a final export at cutover, then a delta check: compare submission totals and the most recent submission timestamp in Jotform with the same figures in Formbricks for the overlap window, and confirm that the webhook or integration you configured in Formbricks received test submissions. Also confirm that uploaded files, which are not always included in a plain CSV export, have been downloaded separately and matched to their records. Confirm these export behaviors against the current Jotform help documentation and your own account, since they can vary by export type.

Changing an embed on a live page is a production change, not a copy edit. Schedule it in a low-traffic window agreed with the web owner, submit the new Formbricks embed or link to a staging copy of the page first, and submit a test response from a device and browser that your respondents actually use. Confirm that the new form loads inside the page layout, that hidden fields arrive with the values the page is meant to pass, and that the old embed is removed in the same change so both forms cannot collect at once. Record the time of the swap in your register, and keep the Jotform form open for a period you set in advance so late responses to the old link are still captured and reconciled.

What drives the cost and duration of a Jotform to Formbricks move

This table lists the factors that change how much work and money a Jotform to Formbricks move takes, with the reason each one matters and how to keep it down. Read it as a checklist for scoping: each driver shows whether its cost is mostly one-time rebuild work or recurring hosting and administration. The main takeaway is that the number of forms and the depth of their logic usually matter more than the platform fees you avoid.

Driver	Why it changes cost or effort	How to keep it down
Number and complexity of active forms	Each active form needs rebuilding, testing and a cutover plan, so the count and structure of forms set most of the one-time effort.	Retire unused forms before migrating, and group similar forms into shared templates.
Conditional logic and hidden fields	Jotform branching and hidden field values must be re-expressed in Formbricks logic and tested path by path, which is slow for deep flows.	Simplify branches where the business rule allows, and document expected outputs for each path before rebuilding.
Volume and size of uploaded files	Past uploads must be exported, checked and moved to your own storage, so large or numerous files add transfer, storage and verification time.	Confirm the file retention rule first, archive files you must keep, and decide which submissions are worth exporting.
Number of website embeds and links	Every embedded form or shared link on your website, emails and documents must be found and swapped to the new survey URL or script.	Build a list of pages and sources before cutover and change them in one controlled release.
Payment and PDF workflows	Formbricks does not replace Jotform payment collection or PDF generation, so each such workflow needs a separate tool, integration and testing.	Identify these forms early, decide the replacement tool, and move only the forms that truly need it into the new stack.
Hosting and administration	Servers, backups, patching, monitoring and access reviews recur for as long as you run Formbricks, and they are often owned by your own team.	Standardize on containers, automate backups and agree on who patches and who is on call before go-live.
Enterprise license need	SSO through OIDC or SAML, teams and access roles, audit logs and whitelabel follow-ups require the Enterprise license, which adds a recurring cost if these features are required.	List which controls your policy requires, check the license documentation, and apply for the license only when those features are needed.
One-time versus recurring costs	Rebuild, testing, data export and cutover are one-time. Hosting, operations, backups and any license are recurring and continue after launch.	Ask any implementation partner for a written scope that separates these two groups, with deliverables for each.

What usually goes wrong and how to prevent it

Most failed Jotform migrations break at the edges: a form nobody remembered, a branch that behaves differently, or a response that never arrived. The cards below cover the failure points we see most often, each with a check to run before the old form is switched off.

Missed forms with live embeds

Forms often sit on pages nobody owns anymore, such as old landing pages, partner portals or PDFs with links. Before cutover, crawl the website and internal wikis for Jotform script tags, iframes and share links, and compare the list with the account's active forms. Give each form an owner and a replacement URL. A form that is only found after the Jotform account is closed will silently stop collecting data.

Logic that changes after rebuild

Conditional logic in Jotform does not always translate one to one. Branches that depend on calculated fields, multiple conditions joined with OR, or jumps to later pages can behave differently in Formbricks. Export each form's logic as a written table, rebuild it, then test every branch with a sample respondent path. Record the expected result for each path so testers can confirm it.

Hidden fields dropped silently

Hidden fields carry values such as campaign IDs, referrer codes or customer reference numbers into submissions. If a hidden field is not recreated, the form still works and the value is simply missing from future responses. List every hidden field from each Jotform form, map it to a Formbricks hidden field or URL parameter, and submit a test response with each parameter populated to confirm it is stored.

Incomplete file exports

Past submissions and uploaded files are exported separately, and file links may stop working when the Jotform account is closed or downgraded. Confirm the export includes every form, date range and attachment, then compare record counts with the source. Store the files in your own object or file storage and keep a manifest that maps each submission ID to its files, so an auditor or data subject request can be answered later.

Responses lost during cutover

A form switch has a window where old and new endpoints both receive traffic, and submissions made during that window can land in the wrong place or nowhere. Plan the switch date, keep the Jotform form live and set to a holding message until the Formbricks survey is confirmed, then reconcile the last day of submissions in both systems. Ask whoever owns the website which URLs will change and when.

Payment and PDF steps forgotten

Forms that take payments, generate PDF receipts or trigger approval emails rely on features Formbricks does not provide. Inventory every integration in each Jotform form, including payment processors, PDF templates, notification emails and downstream connectors. Assign a replacement tool to each one, test it with a real transaction in a sandbox, and do not retire the Jotform form until the replacement has run end to end.

Unclear residency after decommission

Once the Jotform account is closed, the organization still needs to know where copies of responses, uploads and backups remain, and for how long. Ask the vendor in writing how deleted data and backups are handled, and record the answer. On the Formbricks side, document the hosting region, the backup location and a retention period for responses, then set the same rule for exported files so no copy outlives its purpose.

How the migration changes by organization size and starting point

A small team with a handful of forms usually has one or two people who build and publish them, and few or no connections to other systems. The migration is mostly a rebuild exercise: each form is recreated in Formbricks, tested on a preview link, and then swapped into the place where it lives. Because the volume is low, the team can often keep the old Jotform forms open for a short overlap period and close them once responses are confirmed in the new instance.

Form inventory: List every form, its owner, where it is embedded or linked, and whether it still receives responses. Many small teams find forms that nobody has opened in years.
Rebuild scope: Recreate only the forms that are still in use. Simpler forms may fit Formbricks surveys directly, while forms with payment or PDF steps need a separate plan.
Past responses: Export old submissions from Jotform and decide whether they are needed for reporting, retention or audit before importing anything.
Single administrator: Assign one owner for the Formbricks instance and its backups, since no one else may know how it is run.
Community Edition fit: Confirm that the Community Edition covers the features in use, because only one workspace is available in that edition.

Before switching, check that a test submission reaches the team, that notification emails arrive, and that the old embed codes are removed from every page.

Questions teams ask before moving from Jotform to Formbricks

What drives the cost of moving from Jotform to Formbricks?

The cost is mostly labor and hosting, not license fees, because the Formbricks Community Edition can be self-hosted with Docker without a subscription. The main cost drivers are the number of active forms to rebuild, how much conditional logic and how many hidden fields each form uses, whether payment or PDF steps need a replacement tool, and how much server, backup and monitoring capacity your own infrastructure requires. Recurring costs include hosting, storage, patching and administration. One-time costs include form rebuilding, testing and the website embed changes. Ask any implementation partner for a quote built from a written inventory of your forms, so each cost line can be checked against that list.

How long does a Jotform to Formbricks migration usually take?

The timeline depends on the size of the form inventory and how much of it is complex. Forms with branching logic, hidden fields, file uploads, payment steps or PDF generation take longer than simple contact or feedback forms. Other factors include how many embeds sit on live pages, whether past submissions must be exported and reconciled, and how many approvers must review the rebuilt forms before go-live. Because the work is usually fixed-scope, the duration should appear in the written scope and timeline before work starts, and you should confirm the assumptions behind it, especially the number of forms and submissions in scope.

What does our internal team need to provide during the migration?

Your team needs to supply access and decisions, not just time. Expect to provide a list of active Jotform forms with their owners, the submission and file retention rules that apply to each one, the website pages where each embed appears, and the integrations that receive data today, such as email, spreadsheets or CRM connectors. Someone must also approve the hosting location, the access model for staff who view responses, and the test cases that prove each rebuilt form behaves like the original. Without these inputs, rebuilt forms are likely to miss branching paths or send data to the wrong place.

Can our own team migrate from Jotform to Formbricks without a partner?

Yes, a capable team can rebuild simple forms and run the Docker deployment itself, since Formbricks is open source and can be self-hosted without a subscription. The harder parts are reproducing conditional logic and hidden fields accurately, exporting past submissions and uploaded files in a usable form, replacing payment and PDF steps with other tools, and running the instance securely with backups and updates. Many teams do the first pass in-house and bring in outside help for security hardening, testing or compliance evidence. Ask yourself whether anyone on staff will own the platform after go-live, because that ongoing ownership is usually the larger commitment.

What are the Formbricks Community Edition limits?

The Community Edition includes unlimited surveys, responses and users, full API access, website, app, link and email surveys, multi-language surveys, file upload and webhooks. It is limited to one workspace. Single sign-on through OIDC or SAML, teams and access roles, contact management and segments, quota management, audit logs, whitelabel email follow-ups and removing the Powered by Formbricks badge all require an Enterprise license, which is unlocked with a license key. The enterprise code ships in the Docker images, so confirm with Formbricks which features your deployment needs before you design access control and audit evidence around them.

What should we confirm with Formbricks and our export paths before starting?

Confirm five things before work starts. First, whether the Community Edition meets your workspace and access needs, or whether you need the Enterprise license for SSO, roles or audit logs. Second, which Formbricks release you will deploy, using the current release notes on GitHub. Third, which export formats are available for past Jotform submissions and uploaded files, and whether file links remain valid after you cancel Jotform. Fourth, how each payment, PDF and app-building step will be replaced. Fifth, which of your integrations, such as Slack, Notion, Zapier or n8n, have a supported path. Put the answers in the written scope so acceptance tests can check them.

What happens to past Jotform submissions and uploaded files?

Past submissions and uploaded files do not move automatically, so plan an export and a destination before you cancel your Jotform plan. Exports typically come as spreadsheet or data files, while uploaded files need a separate download and storage location in your own infrastructure. Confirm the export format and file retention with Jotform before the plan lapses, and decide how historical data will be linked to the new Formbricks responses. Keep a verified copy of the archive, since retention obligations usually outlast the tool that collected the data.

How DeployOpen scopes and runs a Jotform to Formbricks migration

DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted Formbricks inside your own infrastructure, whether that is your cloud account, a data center or an air-gapped network. Most engagements are fixed-scope, so the forms in scope, the data moves (past submissions, uploaded files and any hidden field values), the cutover of website embeds and the decommissioning of Jotform are agreed in writing before work starts. The written scope is also where you decide which Jotform forms are retired instead of rebuilt, which keeps the rebuild effort tied to forms that are still in use.

Expect the written scope to name the Formbricks edition and any Enterprise license need. The Community Edition covers surveys, responses, the API and webhooks, while OIDC and SAML SSO, teams and access roles, and whitelabel email follow-ups sit under the Enterprise license, so confirm those requirements with your security and identity teams first. DeployOpen does not publish prices. A quote follows from the written scope, so the inputs that move it are the number of forms, the amount of file and submission history to migrate, the number of integrations to rewire, and the hardening and backup standards your organization requires. Ask each bidder to price those items separately so the one-time migration and the recurring costs stay visible.

After cutover, ongoing support, upgrades and continuous testing are available as retainers, so you can choose between handing over operations to your own team and keeping DeployOpen on call for Formbricks version upgrades and patching. Ask any provider to confirm in writing who owns the runbooks, backup restore tests and the documented decommission of Jotform data, including how and when Jotform-hosted uploads are deleted. A useful first step is to read the Formbricks GitHub repository with your platform team so the self-hosting requirements are understood before any scope is signed.

Migrate from Jotform to Formbricks