Amit Kothari
Amit Kothari CEO of Tallyfy · Workflow AI Expert

How to migrate from Jotform to Tallyfy

In brief

Leaving Jotform for Tallyfy is not a data problem, it is a change of job. Jotform builds standalone forms; Tallyfy runs the process a form should start. This guide covers what Jotform Excel, CSV, and PDF exports actually include, how each form concept maps to a Tallyfy blueprint, and the one thing, payment, that stays in Jotform.

Summary

  • Jotform builds forms; Tallyfy runs the process behind them - the move is mostly about deciding which of your forms are the front door to real work, and rebuilding those as processes rather than copying fields one for one.
  • Jotform exports are generous - submissions download as Excel, CSV, or PDF straight from Jotform Tables, and the API hands you forms and submissions for anything programmatic. Getting the data out is the easy half.
  • Payment is the line that stays put - Jotform collects money inside the form; Tallyfy doesn’t. Keep public payment forms in Jotform and let Tallyfy run the workflow they trigger, with the payment as an external step plus an approval.
  • One form is about a week - the multi-page ones with payment and branching take longer. Book a 30-minute migration walkthrough and we’ll be honest about which forms belong in a workflow tool.

If you’re moving off Jotform, the first thing to get straight is what you’re actually moving. Jotform is a form builder, and a strong one. Tallyfy is a workflow tool that happens to start with a form. So the migration isn’t a like-for-like swap; it’s a promotion.

The forms that just collect an answer and email it to someone can keep being forms. The forms that kick off a chain of work, that is, a person has to do three more things after the submit, those are the ones that become Tallyfy processes. Sorting your forms into those two groups is genuinely most of the job, and it’s the same instinct behind settling on workflow software in the first place.

Why teams move off Jotform

Jotform does a lot, and I want to be fair about that before talking about why people leave. It builds forms fast, it has a huge widget library, and it takes payments right inside the form. For collecting structured information from the public, it’s hard to beat.

The wall people hit is the same one every form builder runs into. A form is a single event. Someone submits, the data lands, and Jotform’s part is finished. But the work usually isn’t. A new-vendor form gets filled in, and now someone has to verify the details, get a manager to approve, set up the account, and notify finance. Jotform can email those people, but it can’t run the steps, track who’s stuck, or stop the process when an approval is missing. The form was the easy part; the workflow was everything after it, and that part was a messy follow-up you had to cobble together across inboxes and spreadsheets.

There’s a cost angle too. Jotform meters on submissions per month, so the busier a form gets, the closer you are to a cap or an upgrade. When a form is the trigger for a process you run constantly, paying by submission volume turns out to feel like paying rent on the doorway instead of the house.

What Jotform’s export actually gives you

The export side is refreshingly dull, which is exactly what you want. From Jotform Tables you can download submissions as CSV, Excel, or PDF using Download All, and you can tick specific entries or filter first if you only want a slice. For a backup or a one-time pull, that covers it.

For anything programmatic, the Jotform API gives you both forms and submissions over REST. Worth knowing up front: the API has a daily request cap that scales with your plan, from a thousand calls a day on the entry tier up into the hundreds of thousands higher up, so a big historical pull is something you pace rather than fire all at once.

Solution Forms
Form Builder and Routing Software

Form Building Made Easy

Save Time
Track & Delegate Post-Submit
Consistent Handling
Explore this solution

What the export won’t capture is the form’s design layer, the theme, the custom CSS, the widget behaviour. That’s fine, because you’re not rebuilding the form as a form. You’re reading the export to see which fields you collect and which logic you run, then rebuilding that as the opening step of a process. The submission data is basically the part that matters, and Jotform hands it over cleanly.

How Jotform concepts map to Tallyfy

Jotform happens to be one of the better-documented moves, because the Tallyfy team keeps an explicit object mapping for it. Most things have a clear home.

In JotformIn TallyfyWhat actually changes
FormBlueprintThe form becomes a repeatable process
SubmissionProcess (a run)Each submission is one live instance
Form fieldsKick-off form fieldsCollected when the process starts
Page breakProcess phaseMulti-page forms become phases
Conditional logicStep conditionsShow/hide and skip logic becomes rules
Submit actionsProcess triggersWhat fires after submission
Payment fieldExternal step + gateStays a Jotform/processor job, with a sign-off

Most field types come straight across. Short text, email, phone, number, date, dropdown, and radio map one to one. A few shift shape: a checkbox group becomes a multi-select, a matrix becomes a rating grid, a signature stays a signature, an address splits into its component fields, and a file upload becomes an attachment with the usual size limits. Submit actions, the things Jotform fires after a submission, become process triggers, so an autoresponder email or a Google Sheet append turns into a step the workflow owns rather than a setting buried in the form. The interesting cases are the ones that change category. Your page breaks become phases in the process, so a three-page form turns into a three-phase workflow. Your conditional logic becomes rules, so if you need to turn each branch into a rule, a “yes” on one field can require an extra step or route the run to a different owner.

Concept map showing a Jotform form becoming a Tallyfy blueprint, with page breaks and submissions mapping to phases and runs, and the payment field staying external

Say you run a vendor-onboarding form that also collects a setup fee. In Jotform, a vendor fills it in, pays, and you get a submission. Then a human takes over by hand. In Tallyfy, the same fields become the kick-off form for an onboarding blueprint: verify the vendor, approve the contract, set up the account, hand off to finance. The payment is the one piece that doesn’t move inside, and that’s deliberate. The form keeps collecting the fee (Jotform or your processor handles the money), and Tallyfy stores the reference and adds a payment-cleared approval before the work proceeds. On the concept map above, that’s the orange node off to the side: in the process, but handled outside it.

That payment example is the general rule in miniature. Move the workflow into Tallyfy, leave the money-handling where it already works, and connect them with a reference and a gate.

A realistic migration timeline

Most forms take a week, and the simple ones less. Where it stretches is the forms with payment, deep conditional logic, or a dozen pages, because there’s more to re-express. Anyone promising a one-click import either has a trivial form in mind or hasn’t tried it.

Start by exporting and sorting. Pull your submissions for the record, then look at each form and ask whether it ends at submit or starts something. The contact forms stay forms. The intake, onboarding, and request forms are your migration list. Take the busiest one and map its fields to kick-off fields, turn its page breaks into phases, and rebuild its conditional logic as rules. Add the steps that always came after the submission, the approvals and handoffs that used to be tribal knowledge.

Run one real submission through end to end before you trust it. The first form is the slow one; by the third you’ve got the rhythm. And don’t try to move everything in a weekend.

Why move one form at a time?

Because the point isn’t to rebuild Jotform inside Tallyfy. It’s to turn forms that dead-ended into processes that finish themselves, and that rethink earns the extra care. Do it in a rush and you just rebuild the same scattered follow-up in a shinier tool.

What breaks, and what Tallyfy won’t replace

A handful of things stay behind, and you should know them going in. Calculation widgets go static or become a manual step instead of live math. Custom widgets and embedded HTML don’t transfer. Themes and CSS are gone, which for an internal process is no loss. And if you run HIPAA-regulated forms, the compliance settings get reconfigured in Tallyfy rather than carried over, so plan that with care.

Here’s where Tallyfy stops and Jotform keeps going. Three things, really: built-in payment collection, the library of hundreds of widgets, and the form-builder design polish. Tallyfy is a workflow tool with forms, not a standalone form-and-payment builder. So a public-facing order form that takes a credit card, a slick registration page, a form that leans on a niche widget, those have a good reason to stay in Jotform. Move the forms whose value is the work they kick off, and keep the ones whose value is the public-facing capture itself. The two tools sitting side by side is a perfectly sane setup: Jotform collecting at the edge, Tallyfy running the process behind it.

Quadrant placing Tallyfy as a multi-step workflow that runs after a form submits versus form builders built for a single capture

A multi-step workflow after submit, not a single capture.

Something we notice when teams move off a form tool is how quickly the question changes from “where did the data go” to “where is this work right now.” A pile of Jotform submissions tells you what came in. The same submissions running as Tallyfy processes tell you what’s done, what’s waiting, and who’s holding it up. For forms that start real work, that shift from a data record to a live picture of the work is the whole reason to make the move. AI only sharpens the point, since a defined process is something a model can actually help run instead of guess at.

Common questions about migrating from Jotform

How long does it take to move a form from Jotform to Tallyfy?
About a week for a typical form: export and sort, map fields to kick-off fields, turn page breaks into phases, rebuild the conditional logic as rules, and add the post-submission steps. Forms with payment or heavy branching take longer because there is more logic to re-express.
How do I get my data out of Jotform?
Submissions download as CSV, Excel, or PDF straight from Jotform Tables with Download All, and you can select or filter entries first. For programmatic access the Jotform API returns forms and submissions over REST, with a daily request cap that scales with your plan.
What happens to my Jotform payment fields?
Tallyfy does not collect payments inside a form, so payment is the one piece that stays external. Keep the public payment form in Jotform or your processor, then have Tallyfy store the payment reference and run a payment-cleared approval step before the rest of the work proceeds.
Do my conditional logic and page breaks carry over?
The logic moves, but you rebuild it rather than import it. Page breaks become process phases, and show/hide or skip logic becomes Tallyfy rules using the same IF-THEN thinking. It is hands-on work, and a good moment to prune the conditions that quietly stopped earning their place.
How does the pricing compare?
The two price on different things, so a side-by-side is the fair way to look at it. Our Jotform alternative comparison walks through the positioning, and the Tallyfy pricing page is the single source of truth for current numbers.

Still comparing rather than committed? Our Jotform alternative comparison covers why teams switch, feature by feature, and this guide is the hands-on follow-up once you’ve decided. If you’re coming from a checklist-style tool rather than a pure form builder, moving off Process Street hits a lot of the same beats.

When you want to plan the real thing, the quickest start is a short call where we look at your busiest form and tell you straight whether it belongs in a workflow tool or should stay a Jotform.

Book a 30-minute migration walkthrough and bring the form that generates the most manual follow-up. That’s the fastest way to see the fit.

About the author

Amit is the CEO of Tallyfy. He has 25+ years of practical experience in technology, entrepreneurship, and operational efficiency. He's been hands-on with AI-first engineering and changing Tallyfy to AI-native workflow automation since Claude Code was first released. He's also an Entrepreneur in Residence at WashU's Skandalaris Center, created the OneDay (Woolf) AI curriculum for their accredited MBA and consults with clients who need help with AI via Blue Sheen. He graduated with a Computer Science degree from the University of Bath. He's originally British and lives in St. Louis, MO.

Find Amit on his website , LinkedIn , or GitHub . Read Amit's bio →

Automate your workflows with Tallyfy

Stop chasing status updates. Give people and AI a process to follow.