There's no Tally importer in Fillo, so a migration is a controlled rebuild: preserve the old responses, translate the form into a Fillo schema, reconnect each destination, and switch traffic only after the form and its downstream systems pass a test.

Decide whether the rebuild is worth it

Move when the form needs native product markup, a code-owned schema, signed application identity, or customer-connected file storage. Keep Tally when its hosted experience already fits, or when the form depends on Tally payments, custom domains, or another feature you don't want to replace. Numeric calculations aren't on that list anymore — they rebuild as Fillo calculated fields.

Read Fillo vs Tally before you start.

What doesn't transfer

Form structure: Recreate questions, pages, options, logic, hidden values, and completion behavior.
Responses: Export Tally submissions. They stay a separate archive and don't get Fillo response IDs, schema versions, or delivery records.
Files: Preserve access to old uploads in Tally. New uploads need a Google Drive, Box, or S3-compatible connection in Fillo.
Destinations: Reconnect Sheets, Notion, Slack, Zapier, webhooks, and notifications. Fillo can't infer them from the Tally form.
Tally-only behavior: Redesign payments, custom code, and custom-domain hosting outside Fillo where needed. Numeric calculations are the exception — rebuild them as calculated fields.

Estimate the rebuild

Source form	Migration size
Linear text and choice questions, one completion screen	Small: field mapping, publish, response test, and link replacement
Pages, logic, calculations, hidden values, uploads, or several destinations	Medium: rule-by-rule rebuild and a full branch and delivery test
Payments, custom code, non-numeric calculations, or automations coupled to Tally payloads	Large: product and backend changes before traffic can move

Size describes the kind of work, not how long it takes. Review the live form and its consumers before estimating.

Build the field map

Give fields durable Fillo IDs based on what they store, not the current question label. Labels change; IDs key answers, logic, exports, and downstream code.

Tally source	Fillo target	Check during migration
Short or long answer	`short_text` or `long_text`	Required state and length limits
Single or multiple choice	`select`, `dropdown`, or `multi_select`	Stable option IDs, Other behavior, and shuffled order
Page and conditional logic	Fillo pages, `visibleIf`, and page `next` rules	Every reachable path and early completion
Hidden field or prefilled value	`hidden`, URL prefill, or `initialData`	Parameter names and whether the value is trusted or editable
File upload	`file_upload`	File count, size, accepted types, and connected storage
Numeric calculation	`calculated`	Same inputs and rounding, and each rule or export that reads the result
Payment	Application or external service	Payment status, failure, and return route

Use the field catalog, logic guide, and prefill guide for exact schema shapes.

Preserve the source archive

Export the responses before editing or closing the Tally form. Store the export date, source form ID, timezone, field map, file-access notes, retention owner, and deletion policy beside the archive. Don't merge those rows into Fillo and label them as native responses.

Verify before cutover

Test the published Fillo form with cases that cover:

every required field, option, page, branch, and completion route
URL prefill and hidden attribution values
file upload success, rejection, and storage access
repeat-response, save-and-resume, and signed-identity settings you enabled
the response grid, CSV values, and each destination
narrow and desktop layouts, keyboard focus, errors, and success

If an automation expects a Tally payload, update it to the documented Fillo event or add a server-side translation layer. Don't treat a successful form submit as proof that the destination worked.

Cut over and roll back

Put the Fillo form on a private or low-traffic route and finish the test pass.
Replace one production link or embed first.
Confirm accepted responses and destination delivery in Fillo.
Replace the remaining entry points, then stop new Tally submissions.
Keep the old form and archive read-only for the retention period your organization requires.

Keep the old URL or embed snippet ready until the Fillo path is stable. If validation, uploads, or delivery fail, restore that entry point, repair the Fillo form, and repeat the test. Don't collect production responses in both systems longer than the rollback window — it splits the record of activity.

Cutover checklist

Tally response and file archive has an owner
Field, option, page, and logic map is reviewed
Fillo storage and destinations are connected
Realistic test responses reached every required destination
All public links and embeds are inventoried
Rollback URL or embed is ready
Old and new data retention is documented

Tally help center: Confirm the current source export steps.
Tally features: Inventory behavior that may need a replacement.
Code-defined forms: Keep the Fillo schema in version control.
Uploads and storage: Connect storage before publishing a file field.

Use this page

Migrate from Tally

When an embed stops being enough

Use your components, not an iframe.

Edit once. Validate everywhere.

Know who answered inside your app.

Put uploads where your team works.