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.

Read Fillo vs 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

Publish the Fillo form on a private or low-traffic route.
Replace one Typeform embed or link and watch accepted responses and delivery health.
Move the remaining entry points after the first path is stable.
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

Typeform response exports: Preserve rows and files before rebuilding.
Typeform logic: Inventory branching, calculations, scoring, and endings.
Rebuild a Typeform: Translate a compact flow into Fillo code.
Pages and logic: Define the target navigation model.

Use this page

Migrate from Typeform

A form that feels like your product

The form is part of your page.

The answer lands with its context.

Files go straight to your storage.

Change the UI. Keep one set of rules.