---
title: "Migrate from Typeform"
description: "Plan a Typeform-to-Fillo rebuild with a response archive, question map, branch tests, cutover, and rollback path."
group: "Compare & migrate"
order: 4
type: "comparison"
keywords:
  - "migrate from Typeform"
  - "Typeform import"
  - "rebuild form"
updated: "2026-07-18"
---

Fillo doesn't import a Typeform URL, schema, or response history. The move is a rebuild with four separate jobs: preserve the source data, translate the form, reconnect external systems, and move traffic with a rollback path.

## Decide whether the rebuild is worth it

Move when the form needs native application controls, code review, signed product identity, or customer-connected file storage. Keep Typeform when its conversational presentation, scoring, endings, payment flow, or existing integration is the reason the form works. Numeric calculations alone aren't a reason to stay — they rebuild as Fillo [calculated fields](/docs/fields/calculated).

Read [Fillo vs Typeform](/docs/compare/typeform) before changing the live form.

## What doesn't transfer

- **Questions and logic:** Rebuild pages, fields, options, required rules, branching, variables, hidden values, and endings.
- **Responses and files:** Export both. Historical rows stay an external archive and can't become Fillo responses with versions or delivery state.
- **Integrations:** Reconnect every destination and update any consumer that expects a Typeform payload.
- **Presentation:** Decide whether to keep one question per page or group related questions in the product route.
- **Typeform-only behavior:** Redesign scoring modes, payments, and several answer-specific endings. Numeric calculations are the exception — rebuild totals and derived values as calculated fields instead of an external service.

## Estimate the rebuild

| Source form | Migration size |
| --- | --- |
| Linear questions and one ending | Small: field and page rebuild, publish, response test, and embed replacement |
| Branching, calculations, hidden fields, uploads, or several integrations | Medium: reference mapping and calculated-field rebuilds plus branch, storage, and delivery tests |
| Scoring, payments, several endings, or payload-dependent automation | Large: product and backend changes before cutover |

Estimate from the source form, its Typeform logic map, and its downstream consumers — question count alone won't tell you.

## Build the question map

Typeform question references and Fillo field IDs do the same downstream job: they identify stored answers even when the visible copy changes. Record the mapping before writing the new schema.

| Typeform source | Fillo target | Check during migration |
| --- | --- | --- |
| Short text, long text, email, phone, number, date | Matching typed Fillo field | Required state, bounds, and value format |
| Multiple choice or dropdown | `select`, `multi_select`, or `dropdown` | Stable option IDs and single versus multiple selection |
| One-question screens | One field per Fillo page when the pacing still helps | Progress, keyboard flow, and mobile height |
| Branching and hidden fields | `visibleIf`, page `next`, hidden fields, and prefill | Every path, public parameter, and early exit |
| File upload | `file_upload` | Connected storage, accepted types, count, and size |
| Calculation over numeric answers | `calculated` | Same operands and rounding, and every rule or destination that reads the result |
| Scoring, payment, or several endings | Application or external service | Trusted result, failure path, and final route |

Fillo currently supports one success state or redirect. When a Typeform has several endings, route to an application page that can choose the next screen from trusted response state, or redesign the flow around explicit Fillo pages.

## Preserve the source archive

Use Typeform's response export and download the file-upload archive before the source form changes. Keep the form ID, export date, timezone, question-reference map, file notes, retention owner, and access policy with the archive. A linked spreadsheet is useful for reporting, but it's still Typeform history.

## Verify before cutover

Run matching cases through Typeform and Fillo, then compare:

- stored values and option mappings
- every branch, skipped question, and ending
- invalid input and required-field behavior
- hidden values and prefill
- file transfer and authorized download
- webhook or integration payloads
- desktop, narrow, keyboard, error, and success states

Confirm the accepted response in Fillo and the final state of each required destination. A success screen in the renderer doesn't prove that a later integration succeeded.

## Cut over and roll back

1. Publish the Fillo form on a private or low-traffic route.
2. Replace one Typeform embed or link and watch accepted responses and delivery health.
3. Move the remaining entry points after the first path is stable.
4. Close the Typeform to new responses and keep its archive under the existing retention policy.

Keep the previous embed or URL ready until production traffic is stable. If the new form blocks a valid path or loses a required delivery, restore the old entry point, fix the issue, and repeat the comparison test.

## Cutover checklist

- [ ] Typeform responses and files are exported
- [ ] Question references map to stable Fillo field and option IDs
- [ ] Branches, prefill, validation, and ending behavior are verified
- [ ] Storage and every destination receive a realistic test
- [ ] Public links and embeds are inventoried
- [ ] Rollback URL or embed is ready
- [ ] Historical and new response ownership is documented

## Related

- [Typeform response exports](https://help.typeform.com/hc/en-us/articles/360029253572-Export-your-responses): Preserve rows and files before rebuilding.
- [Typeform logic](https://help.typeform.com/hc/en-us/articles/36047433913364-Which-type-of-logic-should-I-use-and-where-can-I-find-it): Inventory branching, calculations, scoring, and endings.
- [Rebuild a Typeform](/guides/rebuild-a-typeform): Translate a compact flow into Fillo code.
- [Pages and logic](/docs/pages): Define the target navigation model.