GravityImport vs GravityMigrate: which add-on do you actually need?

Partly. GravityImport handles the entry data if you can export it to CSV first—that’s the bridge from Typeform, Jotform, WPForms, Ninja Forms, or any other source that produces a spreadsheet. The form structure itself (fields, labels, conditional logic, settings) doesn’t transfer automatically. You’ll need to rebuild the form in Gravity Forms first, then load the CSV against it. GravityMigrate doesn’t help here either; it only moves data between Gravity Forms sites. For complex source forms, GravityImport’s “auto-create form from CSV” option gives you a starting structure you can refine. See our step-by-step guide to importing entries into Gravity Forms for 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.