---
title: "Migrate from Tally"
description: "Plan a Tally-to-Fillo rebuild with a field map, response archive, test pass, cutover, and rollback path."
group: "Compare & migrate"
order: 3
type: "comparison"
keywords:
  - "migrate from Tally"
  - "Tally import"
  - "rebuild form"
updated: "2026-07-18"
---

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](/docs/fields/calculated).

Read [Fillo vs Tally](/docs/compare/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](/docs/fields), [logic guide](/docs/logic), and [prefill guide](/docs/prefill) 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

1. Put the Fillo form on a private or low-traffic route and finish the test pass.
2. Replace one production link or embed first.
3. Confirm accepted responses and destination delivery in Fillo.
4. Replace the remaining entry points, then stop new Tally submissions.
5. 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

## Related

- [Tally help center](https://tally.so/help): Confirm the current source export steps.
- [Tally features](https://tally.so/help/features): Inventory behavior that may need a replacement.
- [Code-defined forms](/docs/authoring): Keep the Fillo schema in version control.
- [Uploads and storage](/docs/uploads): Connect storage before publishing a file field.