Migrate from SurveyMonkey to Formbricks: what the move involves
Formbricks suits link, website and in-app feedback surveys well, and the main effort in a move from SurveyMonkey is rebuilding those surveys and reworking the integrations that receive their responses. Survey content and results are rarely the hard part. Platform or IT teams usually run the migration, with a named security owner who signs off on where the Formbricks database, uploaded files and respondent contact data sit. Expect the work to be moderate in effort and moderate in risk, mostly concentrated in the cutover period when old and new surveys run side by side. Start with an inventory rather than a copy job. List every live SurveyMonkey survey, its distribution channel (email invitation, public link, embedded website widget or in-app prompt), its response volume, and every downstream destination such as a CRM, a Slack channel, a data warehouse or a spreadsheet. Formbricks has no import path for SurveyMonkey question structures, so each survey is recreated by hand in the Formbricks editor. Some SurveyMonkey logic, scoring or branching may not map one to one, so confirm each construct against the Formbricks documentation before you retire a survey. Ask the vendor or your own test environment to confirm exactly which question types and logic are supported in the version you deploy.
The integration work is where teams most often lose data. SurveyMonkey integrations and webhooks must be re-pointed to Formbricks webhooks, and the receiving systems must accept the new payload format. Formbricks exposes its responses through its API, so pull scripts and reporting jobs need new endpoints, new authentication keys and new field mappings. Run the old and new collection in parallel for a defined period, compare response counts for the same window, and only then disable the SurveyMonkey collector. Archive the SurveyMonkey exports (CSV or XLS, plus any SPSS files your plan permits) into your own retained storage before cancelling, because the historical responses are the part you cannot rebuild. Your security owner should confirm that the Formbricks instance, its backups and its object storage for uploads are inside your approved environment, and that the Community Edition or Enterprise license choice matches the SSO, access role and workspace needs your teams have today.
Which SurveyMonkey capabilities map to Formbricks, and which need rework
This table maps the SurveyMonkey capabilities that a feedback program usually relies on to their closest Formbricks equivalents. Clean means the self-hosted Community Edition covers the capability as documented, needs rework means the survey, integration or data must be rebuilt or reconfigured, and gap means the capability requires the Enterprise license. Check the Enterprise rows first, because SSO, team roles, quotas and audit logs usually decide which edition you need.
| Capability | Formbricks equivalent | Status |
|---|---|---|
| Link and website surveys | Included in the Community Edition, with link and website survey types | Clean |
| In-app feedback surveys | Included, but requires installing the Formbricks SDK in your product code | Needs rework |
| Email-embedded surveys | Included in the Community Edition, with delivery through your own mail server | Needs rework |
| Skip logic and branching | Advanced logic is included in the Community Edition, so rebuild each branch and test it | Clean |
| Multi-language surveys | Included in the Community Edition, but translations must be re-entered per survey | Needs rework |
| File upload questions | Included, with files stored on your server; confirm storage and size settings | Needs rework |
| Quotas for sampling | Quota management is part of the Enterprise license only | Gap in Community |
| SSO and team access roles | OIDC and SAML SSO, teams and access roles need the Enterprise license; Community has one workspace | Gap in Community |
| Contact segments and audit logs | Contact management, segments and audit logs need the Enterprise license | Gap in Community |
| API, webhooks and automations | Full API and webhooks are in the Community Edition; rebuild each automation and confirm payloads | Needs rework |
Which data and integrations move, and which must be rebuilt
Survey work splits into three groups: result data you export and archive, survey content you rebuild in Formbricks, and connections you reattach to new endpoints. Plan each group separately, because a complete results export does not carry logic, triggers or integrations with it.
Exported result files
Responses are the record you must keep, so export them from SurveyMonkey before the plan ends. The export options depend on your plan and account, so confirm in your own account which formats (such as CSV, XLS or SPSS) and which date ranges you can take out. Store the files in your own archive, then check that row counts, timestamps and answer codes match the source before you rely on them.
Question wording and logic
Formbricks does not import SurveyMonkey survey definitions, so question text, answer options, skip logic and hidden fields must be rebuilt by hand. Keep a document that lists each question as it appeared, with its ID and answer codes, so later analysis lines up with the archived results. Mark any question whose wording changed, because a changed question breaks trend comparisons across old and new responses.
Contact and invitation lists
Customer and product feedback often relies on contact lists tied to segments, invitations and opt-out status. Formbricks handles contacts and segments as part of its Enterprise license features, so confirm that requirement before you plan to import contacts with attributes. Do not move a list without a documented lawful basis for contacting each person, and do not carry over opt-outs as if they were never recorded.
Webhooks and API connections
Any SurveyMonkey integration that pushes responses into a CRM, data store or ticket queue must be recreated against Formbricks. Formbricks provides webhooks and full API access in the Community Edition, so rebuild each consumer as a receiver for the Formbricks event payload. Test each receiver with a sample response, and confirm that deleted or edited responses propagate the way your downstream systems expect.
Slack, Notion, Zapier and n8n
Formbricks lists integrations with Slack, Notion, Zapier and n8n among its supported tools. Reconnect each one with its own credentials and channel or database mapping, because the old authorizations do not transfer. Zapier and n8n workflows that read SurveyMonkey triggers need new trigger steps, so review each automation field by field before you turn off the old one.
Historical data and retention
Results you archive are yours to store, but they now sit outside the platform that collected them, so retention and access control become your responsibility. Decide how long archived responses are kept, who can open them, and where personal data in free-text answers is removed. Write these rules down before the SurveyMonkey account closes, since you may not be able to return to it.
Migration sequence from inventory to decommission
This sequence moves customer and product feedback surveys from SurveyMonkey to a self-hosted Formbricks instance without losing responses or breaking the systems that consume them. Each step closes with a named artifact, so the team knows what is finished before the next step starts.
Inventory surveys, links and integrations
Product or CX operations lead, with an administrator of the SurveyMonkey account, lists every survey that collects feedback, including its status, response count, distribution channel (email, web link, embedded widget), question logic and any connected tool such as Slack, Zapier or a CRM. Record where each survey link or embed code appears, including email templates, help center pages and the product itself. The output is a survey register with one row per survey and one row per integration, marked with an owner. The step is done when the owners have confirmed the register is complete.
Confirm Formbricks edition and hosting
Platform owner decides between the Community Edition and the Enterprise license by comparing the register against the feature list in the Formbricks license documentation, such as SSO, teams and access roles, audit logs and removing the Powered by Formbricks badge. Confirm the hosting target, data region and Docker deployment with your infrastructure team. The output is a signed architecture note naming the edition, the environment and who holds the license key if one is needed. Confirm current license terms directly with Formbricks before purchase.
Build and test a pilot survey
Survey designer rebuilds one low-risk, representative feedback survey in the self-hosted Formbricks instance, choosing the link, website or in-app type that matches its current channel. Run test responses on desktop and mobile, check logic branches, multi-language versions and file upload fields, and confirm the response data appears correctly in the Formbricks dashboard. The output is a pilot survey with a test log listing each check and its result. Do not move the production traffic yet.
Build and verify webhooks and API consumers
Integration engineer recreates each integration that depends on survey responses, using Formbricks webhooks or the API, and points it at a staging endpoint. Send a test response and confirm the downstream tool receives the full payload, including hidden fields and metadata that your reports use. Document any SurveyMonkey field that has no direct equivalent and decide how it will be mapped. The output is a tested webhook or API integration record for each consumer, signed off by its owner.
Run both tools in parallel
Survey owner publishes the rebuilt surveys in Formbricks alongside the live SurveyMonkey versions, with the same questions and wording, and watches both for a defined period agreed in advance. Compare response counts, completion rates and sample data from each tool, and reconcile any gaps caused by distribution differences. The output is a parallel-run report with the reconciliation results and a go or no-go decision recorded by the project owner. Keep SurveyMonkey collecting until this report is approved.
Cut over links, embeds and triggers
Web and product teams replace every survey link, embed code and in-app trigger from the register with its Formbricks equivalent, and update email templates and help pages in the same change window. Close the old SurveyMonkey collectors so no new responses arrive there, and keep a dated record of each change. The output is an updated register where every row points to Formbricks and a check that no old collector is still live. Verify by submitting a response through each channel.
Export and archive historical results
Before the SurveyMonkey plan ends, the data owner exports every survey's responses, question text, and metadata in the formats the plan allows, then stores them in an access-controlled archive on your own servers with a checksum and a retention label. Confirm with the archive reviewer that a reader can open the files and match them to the survey register. The output is a signed-off archive with an index. Only after this sign-off should the SurveyMonkey account be closed.
Decommission SurveyMonkey and document closure
Platform owner removes remaining SurveyMonkey integrations and API tokens, cancels the subscription after confirming the archive, and records the final state in the change log. Schedule a review of the Formbricks instance for backups, access and updates. The output is a closure record listing the archive location, revoked credentials and the named owner for the self-hosted instance. This closes the migration.
How to run both tools in parallel and cut over safely
Keep SurveyMonkey collecting live responses until every Formbricks survey has been checked end to end, and only then switch traffic. The safest order is to build each Formbricks survey as a link survey first, send test responses from a staging environment, and confirm that the answers land in the right survey and workspace before any respondent sees the new version. Because the Formbricks Community Edition is limited to one workspace, decide early whether a single workspace can hold the feedback programs you run today, or whether the Enterprise license is needed before you split surveys across teams.
Switch the entry points one at a time. Website and in-app embeds are the highest-risk items because the Formbricks SDK must be installed with the correct environment ID and must not fire on pages where the old SurveyMonkey widget still runs, which would double-count prompts. Replace the embed on a low-traffic page or a test segment first, then move email invitation links, QR codes and any help-center links. Keep the SurveyMonkey collector open with a closing message that points respondents to the new survey, so anyone who opened an old link during the switch is not left with a dead end. Record the date of each change in a cutover log so that you can tell later which responses came from which version.
Responses that arrive during the switch need a named owner and a rule. Export SurveyMonkey results at the cutover point, then merge them with Formbricks responses by timestamp and respondent identifier, and check for duplicates from respondents who answered both versions. Before you turn off SurveyMonkey, confirm webhook delivery: send a test response, verify that the downstream tool received the payload, and check Formbricks webhook logs for failed deliveries. Typeform's Responses API documentation notes that submissions from roughly the last 30 minutes may be missing from a query, which is a useful reminder to re-query recent windows and reconcile counts. Do not assume SurveyMonkey behaves the same way. Confirm its export and API timing with SurveyMonkey before you rely on it, and keep the final export until counts match for at least one full reporting cycle.
What drives cost and duration in this migration
This table lists the main drivers of effort and spend when moving SurveyMonkey surveys to self-hosted Formbricks, with who pays for each component and how to keep it down. Read it before requesting a quote, because the drivers decide whether the work is a short rebuild or a multi-stage program. The main takeaway is that the Community Edition removes recurring response fees, but the one-time rebuild, integration work and hosting effort still scale with your survey estate.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Live surveys and logic complexity | Each live survey must be rebuilt, tested and re-pointed at its links or pages. Branching, piping and hidden fields multiply test cases. | Inventory surveys first, retire inactive ones, and rebuild the simplest flows before complex branching. |
| Integrations and webhooks | Every SurveyMonkey connection to a CRM, spreadsheet or collaboration tool must be mapped to a Formbricks webhook or to an integration such as Slack, Notion, Zapier or n8n. | List each connection with its owner and payload fields, and remove integrations nobody still uses before rebuilding. |
| In-app SDK installation across products | In-app surveys need the Formbricks SDK in each product, with separate environment keys, user attributes and testing on each release path. | Start with one product, confirm targeting and frequency rules, then roll out to other products in separate releases. |
| Community versus Enterprise edition needs | The Community Edition covers unlimited surveys, responses and users with full API access, but one workspace only. OIDC or SAML SSO, teams and access roles, and audit logs need the Enterprise license key. | Write down which SSO, role and audit requirements are mandatory, and decide the edition before design work starts. |
| Hosting and backup setup | You pay the infrastructure provider for servers, storage, database, backups and TLS certificates. These recur monthly or yearly, and backup and restore testing is one-time setup plus ongoing checks. | Ask for a sized architecture with a single-node Docker or Helm option, backup scope and a tested restore procedure in the written scope. |
| Historical data archive | Exporting past responses, files and metadata from SurveyMonkey and loading them into your archive is one-time effort. Format conversion and access control for the archive are the main variables. | Agree which fields and years must be kept, and store the export in a format your retention policy already accepts. |
| Staff training | Survey owners, analysts and developers must learn the new builder, logic model, API and webhook behavior. Training is one-time per role, with refreshers when staff change. | Train a small group of power users who own surveys, and document the rebuilt templates for everyone else. |
| Implementation partner and support | Fixed-scope implementation is a one-time fee set by written scope. Ongoing support, upgrades and testing are recurring if you choose a retainer, and your internal staff time is an ongoing cost either way. | Ask for deliverables, acceptance criteria and handover documents in the quote, and separate one-time work from any retainer line. |
What usually goes wrong and how to prevent it
Most failed survey migrations fail quietly after go-live, not during the build. The cards below cover the failure points we see most often when feedback surveys move from SurveyMonkey to Formbricks, with a prevention step for each.
Broken embeds after cutover
Website and in-app surveys depend on the environment ID and the JavaScript or SDK snippet that points at your self-hosted domain. If the old SurveyMonkey links or embed code remain on pages, responses stop arriving with no error on your side. Before cutover, inventory every page, mobile build and email template that references a survey, replace each reference, and test submissions from each channel on the production domain.
Lost historical results
Formbricks is not a drop-in importer for SurveyMonkey response history, so older results can be left behind when the subscription ends. Export every survey's responses, question text and answer options to CSV or another format you can read later, and store them in an archive your records policy covers. Confirm with your retention owner which exports are kept as the system of record.
Webhooks that silently stop
Webhooks forward responses to Slack, Zapier, n8n or a CRM, and a failing receiver can stop deliveries without a visible alert in the survey tool. Assign an owner for each webhook, send a test response after every change, and add a daily count check that compares Formbricks responses with the receiving system. Document the endpoint URL and the secret used to sign requests so a rotation does not break the flow.
Unclear ownership of respondent data
Once you self-host, your organization is responsible for where respondent names, email addresses, contact attributes and free-text answers are stored and who can read them. Define who administers the server, who can export responses and how long contacts are kept. Record the data flows in your records of processing and confirm them with your privacy office before inviting customers to respond.
Single workspace limit on Community
The Community Edition allows only one workspace, so product, support and regional teams that expect separate survey spaces may end up sharing one environment with mixed access. Map your teams and their access needs before you choose an edition. If you need multiple teams with separate roles, price the Enterprise license in writing, or decide how one workspace will separate surveys by team.
AGPLv3 obligations for private forks
The core application is licensed under AGPLv3, and privately kept forks must be released under AGPLv3 unless an Enterprise license covers them. Teams that customize the survey UI or add internal integrations inside a fork can create source disclosure duties, including for users who interact with it over a network. Keep custom code in separate services that call the public API, and have counsel review any fork before it is deployed.
How the migration differs by team size and starting point
A small team with a handful of link or website surveys usually has the simplest move. The work is mostly rebuilding a few surveys in Formbricks, confirming that each one collects the answers the team reports on, and archiving the old results before the SurveyMonkey plan ends. The Community Edition covers the feature set most of these teams need, so the main decision is whether one workspace is enough.
- Inventory first: List every live survey, its audience, its open dates and the questions that feed reports or decisions.
- Export before cancelling: Download responses and question-level data from SurveyMonkey while the plan is still active, and store the files in a location the team controls.
- Rebuild a minimal version: Recreate the questions that matter, then test link and website placements on a staging instance before going live.
- Confirm one workspace is enough: The Community Edition allows a single workspace, so check whether products or teams need separate spaces.
- Keep reporting simple: Agree on the few charts or exports people actually use, and rebuild only those.
Before switching a live survey, confirm with the team which fields in old exports must still match the new responses.
A larger team often runs many in-app surveys, feeds responses into a CRM, a ticketing tool or a chat channel, and depends on a stack of automations. Here the migration is mostly about the integration map. Each survey trigger, webhook and downstream consumer has to be found, rebuilt and tested, or responses will quietly stop arriving where people expect them.
- Map every consumer: Record each webhook, Zapier or n8n flow, and API call that reads SurveyMonkey data, along with who owns it.
- Rebuild in-app triggers: Recreate in-app and website surveys with the same targeting rules, and check that the Formbricks SDK is installed on every page or app version that needs it.
- Reconnect through webhooks and the API: Formbricks integrates with Slack, Notion, Zapier and n8n and supports webhooks and full API access in the Community Edition. Test each route with sample responses before cutover.
- Run both systems in parallel: Keep SurveyMonkey collecting while Formbricks receives responses from a subset of traffic, then compare counts and payloads.
- Plan for historical data: Decide whether past results are imported, archived as files, or kept read-only in another store.
Confirm with each downstream owner what payload shape and timing they expect, because field names and delivery behavior may differ from SurveyMonkey.
Organizations that require single sign-on, role-based access, audit logs or whitelabel follow-up emails will find that these sit in the Enterprise license rather than the Community Edition. The move therefore starts with a licensing and governance decision before any survey is rebuilt. The Enterprise code ships in the Docker images and is unlocked with an Enterprise License Key, so the choice affects how the deployment is configured and who approves it.
- List required features: Document which of OIDC or SAML SSO, teams and access roles, contact management, quota management, audit logs and whitelabel email the program needs.
- Get a quote for the license: Ask Formbricks for pricing against the stated feature list and seat or workspace needs, since no price is given here.
- Set identity and access early: Connect the identity provider and define roles before inviting survey editors, so access is controlled from the start.
- Document audit and data handling: Confirm how audit logs are retained and exported, and where respondent data is stored in the self-hosted environment.
- Review the license terms: Privately kept forks must be released under AGPLv3 unless an Enterprise license applies, so have legal review any custom modifications.
Before committing, confirm with the vendor which Enterprise features are included in the quoted tier and how the license key is issued and renewed.
Questions buyers ask before moving from SurveyMonkey to Formbricks
Can our team migrate from SurveyMonkey to Formbricks without an outside partner?
Often yes, if one or two people own the surveys and someone can run Docker and manage a server. Formbricks can be self-hosted with Docker without a subscription, so the software itself is not a barrier. The harder part is usually the rebuild: each survey must be recreated as a link, website or in-app survey, and the logic, hidden fields and triggers need checking. Before deciding, list your active surveys, the integrations attached to them and who maintains the server after go-live. If those are small and well understood, an internal migration is realistic. If several teams depend on the feedback flows, a fixed-scope engagement with written deliverables can reduce risk. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure, and it can be scoped either way.
What drives the effort of moving surveys to Formbricks?
The main drivers are the number of surveys, how complex their logic is, and how many integrations depend on them. Simple link surveys move quickly. In-app or website surveys need the Formbricks SDK installed in the product, which involves engineering time and testing across environments. Integrations are the next factor: Formbricks integrates with tools such as Slack, Notion, Zapier and n8n, and webhooks or the API must be reconnected and verified. Historical data is another driver, since deciding what to archive affects how much export and storage work is needed. Ask any provider for a breakdown by survey, integration and environment so you can see which items carry the cost.
How long does a SurveyMonkey to Formbricks migration usually take?
No duration can be stated from the supplied research, so treat any timeline as an estimate to confirm in writing. In general terms, the schedule depends on survey count, SDK installation in your product, the number of integrations, security review of the server, and how quickly your team can test. A small set of link surveys with one integration is a different project from dozens of in-app surveys feeding several systems. Plan for a parallel period in which SurveyMonkey and Formbricks both run, so responses are not lost while you verify. Ask for milestones and acceptance criteria before work starts.
Is the free Community Edition of Formbricks enough for product feedback?
For many product and customer feedback programs, the Community Edition covers the core needs. It includes unlimited surveys, responses and users, full API access and all SDKs, link, website, app and email-embedded surveys, multi-language surveys, file upload and webhooks. The main limit is that it supports one workspace. Teams that need several separate workspaces, or that want SSO or role-based access, should check the Enterprise option. The Community Edition is licensed under AGPLv3 for the core application, and privately kept forks must be released under AGPLv3 unless covered by an Enterprise license. Have your legal team confirm this fits how you plan to modify the software.
How does the Enterprise license affect SSO and access roles?
Self-hosted Formbricks needs the Enterprise license for OIDC and SAML single sign-on, teams and access roles, contact management and segments, quota management, audit logs, whitelabel email follow-ups and removing the Powered by Formbricks badge. The enterprise code ships in the Docker images and is unlocked with an Enterprise License Key, so you do not install a separate build. Before buying, confirm with the vendor the current price, the license term and what happens at renewal. Identify which of your teams need role separation or audit trails, because those requirements decide whether the license is needed at all. Check your identity provider's SAML or OIDC settings with your own security team.
Can we archive our SurveyMonkey results before the subscription ends?
Yes, but the export must happen while the account is still active. What you can take out depends on your SurveyMonkey plan, so check the export formats available to you before cancelling. Export results, question wording, respondent metadata that you are permitted to keep, and any files attached to responses. Store the archive in your own infrastructure with a retention schedule that matches your policy, and record which surveys it covers. Formbricks is built for new feedback collection, so historical SurveyMonkey data usually sits in the archive rather than being imported into Formbricks. Confirm with your data protection lead how long personal data should be kept.
What does our team need to provide during a Formbricks migration?
Your team needs to name a survey owner for each program, provide access to the product where in-app surveys will run, and supply credentials for the integrations to be reconnected, such as Slack, Notion, Zapier or n8n. An engineer must install the SDK, confirm webhooks and API calls, and approve the server hosting plan. Someone must also own backups, updates and monitoring once the platform is live, since self-hosting shifts operations to your organization. Agree these responsibilities in writing so that no step is left without an owner.
How do webhooks and the API replace SurveyMonkey integrations?
Each SurveyMonkey integration should be listed and mapped to a Formbricks webhook or API call before cutover. Formbricks supports webhooks and full API access in the Community Edition, so many flows can be rebuilt without a license upgrade. Test each one with sample responses, check payload fields, and confirm that downstream systems handle the new structure. Pay attention to retries and failure handling, since a broken webhook can lose feedback silently. Keep SurveyMonkey and Formbricks running in parallel until every integration has been verified.
How DeployOpen scopes and runs this 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. The work usually runs under a fixed-scope written agreement that sets out which surveys are rebuilt, which integrations are reconnected, where the server runs and what documentation you receive before work starts. A quote follows from that written scope, so the first step is an inventory of your active SurveyMonkey surveys, their distribution channels (link, website or in-app), the webhooks and connected tools in use, and the export files you need to keep. Ask for the scope to name each of these items explicitly.
Expect the scope to separate one-time work from recurring work. One-time work includes provisioning the Formbricks host and database, deploying with Docker or the Helm chart, configuring the Community Edition or Enterprise license decision, rebuilding surveys, archiving SurveyMonkey results, and testing webhooks and API calls against a staging instance. Recurring work covers upgrades, backups, monitoring and security patches. Ongoing support, upgrades and continuous testing can be covered by a retainer, which you can scope separately from the migration. Confirm with DeployOpen how each item is priced and which environment costs, such as hosting, email delivery and domain certificates, remain with your team.
Before you sign, confirm three things in writing: who holds administrative access to the server and database, how backups of response data are encrypted and where they are stored, and what acceptance tests prove that each rebuilt survey and integration works. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications, so any requirement for a formal assessment should be assigned to an independent auditor. Agree a cutover window with your team so that the SurveyMonkey collectors are switched off only after the new links and webhooks have been verified.

