Published
•
Updated
GravityImport vs GravityMigrate: which add-on do you actually need?
Confused between GravityImport and GravityMigrate? GravityImport handles CSVs into entries; GravityMigrate moves entire Gravity Forms setups between sites.
Both add-ons enable you to “import” data into Gravity Forms, and that’s where the confusion lies. If you’re trying to get data into Gravity Forms but can’t tell which add-on fits the job, this guide will get you to the right answer!
Quick decision guide (pick in 30 seconds)
- You have a CSV file and want to load its rows as Gravity Forms entries? Use GravityImport.
- You have an entire Gravity Forms setup on one site and want to move it to another site (forms, entries, feeds, Views, settings, the lot)? Use GravityMigrate.
- You have forms in another WordPress form plugin (WPForms, Ninja Forms, Contact Form 7, and others) and want them in Gravity Forms? Use GravityMigrate for the forms, then export their entries to CSV and bring them in with GravityImport.
- You’re moving a site, but you also have CSV data sitting outside Gravity Forms? You’ll want both. GravityMigrate handles the form/entry transfer; GravityImport pulls the CSV rows in afterward.
The simplest mental model: GravityImport brings in rows from a spreadsheet, GravityMigrate moves forms and everything built around them.
What each plugin actually does
GravityImport is a CSV importer for Gravity Forms. You upload a CSV, map its columns to form fields, and the rows become entries. It can drop those rows into an existing form or auto-build a new form whose structure matches your spreadsheet. It’s designed for jobs that start with a flat file: a list of customers, a member directory you exported from another tool, a set of survey responses sitting in a Google Sheet.
GravityMigrate carries a whole Gravity Forms setup. Between two WordPress sites, it bundles forms, entries, uploaded files, Views, add-on feeds, Gravity Flow workflows, and settings into a single ZIP file you download from one site and import into the other. That’s for jobs that start with a working Gravity Forms install on Site A and end with a copy of that install on Site B. Staging to production. Demo to live. Old domain to new.
GravityMigrate also moves forms between Gravity Forms and seven other form plugins on the same site: Contact Form 7, Fluent Forms, Formidable Forms, Forminator, Ninja Forms, WPForms, and WS Form. Before each form migrates, it shows what carries over and what changes. Only the forms move. The entries stay in the plugin that collected them, which is where GravityImport comes in.
Side-by-side comparison
| GravityImport | GravityMigrate | |
|---|---|---|
| Primary job | Import CSV rows as entries | Move entire Gravity Forms setups between sites, and move forms to and from other form plugins |
| Source format | CSV files | A ZIP file generated by GravityMigrate on the source site, or the forms of another form plugin on the same site |
| What it imports | Form entries (and metadata when columns are mapped). Can also create a new form to match the CSV structure. | Between sites: forms, entries, uploaded files, Views, add-on feeds, Gravity Flow workflows, and settings. From another form plugin: the forms only |
| Field mapping | Yes. You map each CSV column to a form field, or skip it | Automatic. Between sites, the original structure is kept. From another form plugin, GravityMigrate maps each field and shows what changes before it runs |
| Updates existing entries? | Yes. If you include an Entry ID column then matching rows are updated | No. The migrator creates new forms rather than merging into existing ones |
| Bulk capability | Built for thousands of rows in one pass; failed rows can be exported as CSV for review | A single export bundles whatever you select; one-shot transfer per ZIP |
| Triggers feeds (Mailchimp, Zapier, User Registration, etc.)? | Optional, off by default. Toggle “Run feeds for each imported entry” | Migrates the feed configurations themselves (not entry-by-entry triggers). Add-ons must be installed and activated on the destination site for the feeds to render |
| Sends notifications during import? | Optional, off by default | Not a notification-firing tool; it transfers the configuration |
| Validation | Validates each row; can skip required fields and continue past errors | Validates the ZIP’s integrity; once imported, changes can’t be undone |
| Requirements | Gravity Forms installed and activated on the same site | Gravity Forms 2.5 or later on both sites. For a plugin migration, the other plugin active on the same site |
| Pricing | Sold standalone (starting at $99 per year) or bundled in the All Access Pass ($396 per year) | Sold standalone (starting at $99 per year) or bundled in the All Access Pass ($396 per year) |
Real-world jobs and which product handles each
You need GravityImport when…
- You have a list of 5,000 customers in a CSV and need them as entries in an existing customer form. Map columns, click import, done.
- You’re starting a directory and have your seed data in a spreadsheet. Upload the CSV and let GravityImport auto-create the form to match.
- You need to update existing entries in bulk. Add an Entry ID column to your CSV and GravityImport will switch into update mode for matching rows. (This will override existing entries with the new data).
- You’re bringing submissions over from another form tool or CRM (Typeform, Jotform, HubSpot, or a WordPress form plugin) and you’ve exported them to CSV. GravityImport is the bridge from spreadsheet to Gravity Forms. If the source is one of the WordPress form plugins GravityMigrate supports, move the form with GravityMigrate first, then import the entries into it.
- You want imported entries to trigger a Mailchimp feed, fire a notification, or run through a User Registration feed. Turn the relevant options on during import and each row runs through your normal Gravity Forms automation.
You need GravityMigrate when…
- You’re cloning your staging site into production and want forms, entries, feeds, Views, and settings to land on the live site exactly as they were.
- You’re moving a client site to a new domain or host and you don’t want to rebuild every form, feed, and View by hand.
- You want one of GravityKit’s online demos on your own site. GravityMigrate has a documented workflow specifically for this.
- You want to build a reusable template. Build out a full Gravity Forms-powered application with forms, Views, feeds, workflows, and more. Then bundle it into a ZIP that you can reuse for multiple clients.
- You need to bring a Gravity Flow workflow (or a Nested Forms parent/child setup) along with the entries. GravityMigrate carries those configurations across; GravityImport does not.
- You’re switching to Gravity Forms from another WordPress form plugin such as WPForms, Ninja Forms, Formidable Forms, or Contact Form 7. GravityMigrate recreates the forms and tells you what changes in each one before it runs. Bring the entries across afterward with GravityImport.
Frequently asked questions
Yes, from seven WordPress form plugins: Contact Form 7, Fluent Forms, Formidable Forms, Forminator, Ninja Forms, WPForms, and WS Form. GravityMigrate recreates each form in Gravity Forms with its fields, conditional logic, confirmations, and notifications, and shows what changes before it runs (the guide to migrating forms from another form plugin has the details). Entries stay behind, so export them to CSV and import them into the new form with GravityImport. For tools outside that list, such as Typeform or Jotform, GravityImport’s “auto-create form from CSV” option gives you a starting structure, and our step-by-step guide to importing entries into Gravity Forms covers the full workflow.
GravityMigrate explicitly carries Gravity Flow workflows, Nested Forms parent/child relationships, file uploads, and feed configurations in the migration ZIP. Other add-ons (Signature, Webhooks, etc.) generally travel as part of the form configuration since their data is stored in the entry, but the destination site needs the matching add-on plugin installed and activated before you import, otherwise those fields render empty even though the data is there. For mission-critical migrations, run a test import on a staging site first and verify each add-on’s data renders correctly before cutting over.
Neither. GravityMigrate creates new forms on the destination by default, with fresh form IDs. Your existing forms on the destination site stay untouched, and the imported forms appear alongside them in the Forms list. The trade-off: imported entries land on the new (imported) form, not your existing one. If your goal is “merge new entries into a form I already have”, that’s a GravityImport (CSV) job, not a GravityMigrate one. One thing to watch: importing the same export twice creates duplicate forms on the destination. Back up before importing if you’re not sure whether the import has already run.
Yes. GravityKit licenses don’t count development or staging sites against your activation total. The auto-detection happens automatically for common patterns like staging.example.com, dev.example.com, localhost.local, and most managed-host staging URLs. If your staging URL is unusual (custom subdomain, regional domain, or a multisite network), contact support and the team can manually adjust your activation limit.
Three common causes. First, the CSV file: malformed encoding (non-UTF-8), inconsistent column counts, or unescaped commas inside cells will stall the importer. Re-save the file as UTF-8 from Google Sheets or LibreOffice before re-uploading. Second, server limits: large imports (10,000+ rows) can hit your hosting’s PHP timeout or memory limits. Increase max_execution_time and memory_limit if you can, or split the CSV into smaller batches. Third, plugin conflicts: temporarily deactivate caching, security, and optimization plugins, run the import, then reactivate them. Gravity Forms’ common form issues checklist covers the standard server-side fixes if those don’t resolve it.
Yes, entry IDs change. GravityMigrate creates fresh entries on the destination, so an entry that was ID 1247 on the source might land as ID 39 on the destination. The data is the same, but the IDs are renumbered to fit the destination’s existing entry sequence. If you have URLs that reference specific entry IDs (single-entry GravityView URLs, custom redirects, or external integrations holding entry-ID references), those will need to be updated after the migration. The simplest path: run a search-and-replace across your saved URLs after migrating, then click through to verify. For sites where entry IDs are part of public-facing URLs (member directories, ticket trackers), plan a brief redirect window or migrate to a slug-based URL pattern before the migration.
Get better at Gravity Forms, one email a week
New GravityKit releases, practical Gravity Forms tutorials, and subscriber-only discounts. One short email every week, unsubscribe anytime.
More articles
Launch Log: A range slider for search, AI-managed calendars, and security updates in ten products
GravityView adds a Slider search input, GravityCalendar lets AI assistants manage calendars, and ten GravityKit products get security fixes. Here’s what shipped.
9 nonprofit apps you can build with Gravity Forms and GravityKit
Nine apps nonprofits build on WordPress from Gravity Forms data: volunteer databases, member directories, client portals, donation pages, grant review and more.
How to migrate from Fluent Forms to Gravity Forms without rebuilding your forms
Move your Fluent Forms forms into Gravity Forms with GravityMigrate, then bring your entries across with GravityImport. Every step was tested on the free version of Fluent Forms.