GravityKit GravityMigrate - WordPress Plugin

GravityKit GravityMigrate Guide: Move Gravity Forms Between Sites Without Rebuilding Everything by Hand

GravityKit GravityMigrate is not meant for a simple export of one table of submissions. It is designed to move an entire working Gravity Forms environment between WordPress sites. This guide walks through a practical use case: how to prepare the source site, what to select during export, how to import the ZIP package into the new site, and how to verify forms, entries, files, Views, feeds, workflows, and related settings after the move.

This article is written for administrators, developers, small project owners, or agencies that already use Gravity Forms and want to move working forms without manually rebuilding fields, entries, Views, and integration settings. It includes a step-by-step workflow, but that does not replace a test migration: any data move should be tested on a copy of the site first.

The core idea is simple: before you import anything, you need to understand exactly what is being moved, which dependencies must be installed on the new site, and how you will verify the outcome when the process is finished. When handled that way, GravityMigrate saves time and reduces the risk of human error. If you import an unprepared package directly into a live site, you can end up with duplicate forms, broken external integrations, inaccessible uploaded files, or Views that look different because of the theme.

What the Plugin Actually Moves and Where Its Responsibility Ends

GravityMigrate works inside the Gravity Forms ecosystem. Its job is to collect Gravity Forms data and compatible add-on data from the source site into a single portable ZIP file, then import that package into another WordPress site. According to GravityKit's official materials, the package can include forms, entries, uploaded files, feed configurations, GravityView Views, Gravity Flow workflows, Nested Forms data, settings, and other related add-on data if they are supported and selected during export.

That is an important difference from the standard Gravity Forms export. Native form export helps you move the form structure, but it has never covered the full chain of entries, files, feeds, and external add-ons in one package. Native entry export gives you a data file for analysis or separate import, but it does not create a full copy of a working configuration. GravityMigrate is built for the specific case of "I already have a working Gravity Forms setup, and I want to move it to another WordPress site."

The second distinction is that import should not be treated as synchronization. The official FAQ clearly states that if the form being moved already exists on the new site, GravityMigrate creates a copy instead of overwriting the existing form. This is a non-destructive import: it protects your current forms from accidental overwrite, but it also means you need to clean up duplicates carefully after testing.

The third boundary is that GravityMigrate does not move data into a different form builder. If the destination site uses Contact Form 7, WPForms, or another form plugin, this plugin will not convert a Gravity Forms structure into that other format. It is also not a one-click server-to-server migration tool: according to the documentation, the process is built around exporting a ZIP file from the source site and importing that same ZIP file into the destination site.

Who GravityMigrate Is Best For and When Another Route Makes More Sense

This plugin is especially useful for anyone using Gravity Forms for more than a single contact form. That might mean an application directory powered by GravityView, an internal approval workflow handled by Gravity Flow, a registration form with document uploads, a training portal with nested submissions, a client-facing GravityKit app, or a staging copy of a complex project. In those cases, moving things manually turns into a long chain of work: recreate the forms, restore conditional logic, move entries, verify uploads, rebuild feeds, update Views, and make sure the workflow did not lose any steps.

GravityKit GravityMigrate is also convenient for agencies because the move can be repeated as a controlled operation. For example, a team might build a form and a View on a staging site, populate it with a few test entries, get client approval, and then move the finished setup to production. Instead of clicking through dozens of settings in the new environment, the team exports the selected forms and related data, imports the package into the target site, and verifies the result against a checklist.

The product also helps site owners who are changing domains or building a new site alongside an old one. If the entire WordPress site is already being moved with a separate tool, GravityMigrate may not be necessary. But if you are only moving part of the forms setup or a standalone GravityKit app, a dedicated product-level migration tool is safer than manually editing the database. Gravity Forms stores entries, metadata, notes, feeds, and form settings across multiple tables, so moving rows directly without understanding the schema can easily break those relationships.

It is not the best option for a one-time import of lead data from a CRM or Excel. That kind of task requires mapping, validation, and work with CSV columns. GravityKit's official comparison makes the roles explicit: GravityImport loads CSV rows as entries, while GravityMigrate moves an entire Gravity Forms environment between sites. If your goal is not to preserve a connected project but to load an external list of submissions, GravityMigrate is the wrong tool.

Another weak fit is any migration where you do not have access to the required add-ons. If the form on the old site uses GravityView, Gravity Flow, Nested Forms, Zapier, or payment add-ons, the necessary plugins must also be installed and activated on the new site. Otherwise, the data may import, but the interface, field type, or feed may not display or function correctly. GravityMigrate moves data and configuration, but it does not replace missing destination plugins.

What to Check Before Installation and Your First Export

Preparation matters more here than the export button itself. GravityKit's official best practices start with Gravity Forms compatibility, current GravityMigrate versions on both sites, the required add-ons on the destination site, and ZIP file validation. In practice, it also makes sense to add standard migration safeguards: a backup, a test import, a dependency list, and a clear rollback plan.

Platform and Dependent Plugin Review

WordPress, Gravity Forms, and GravityMigrate should all be active on both the source and destination sites. GravityMigrate documentation states that Gravity Forms must meet the product's supported version requirements, and Gravity Forms' own general requirements also emphasize that add-ons depend on Gravity Forms Core and an up-to-date server environment. In practical terms, that means one simple thing: before the move, open the Gravity Forms system information, make sure the site is not running outdated PHP, and update plugins on a test copy rather than directly on the live project.

Next, make a list of the add-ons that affect the setup you are moving. For GravityView, you need GravityView itself and any extensions used by the View for additional layouts or fields. For Gravity Flow, you need the workflow plugin because moving workflows without the engine that runs them has no value. For Nested Forms, you need Gravity Wiz Nested Forms, or the parent-child structure will lose the expected field and interface. For Zapier, remember that feed settings may transfer, but the Zap on the Zapier side still needs to be checked after a domain change.

Backup and Test Environment

GravityMigrate import does not overwrite existing forms, but that does not eliminate the need for a backup. The plugin can create new forms, entries, Views, files, and feeds. If you import the wrong package, there is no one-click way to roll it back. The official FAQ explicitly warns that an import cannot be undone or reversed after completion. The safe approach is to back up the database and uploads first, import the ZIP into staging or a temporary site, verify the outcome, and only then repeat the operation on production.

Practical rule: if an import cannot be removed quickly by hand without risking live entries, it needs to go through a test copy first. Non-destructive behavior protects existing forms from being overwritten, but it does not make the import reversible.

Permissions, Package Size, and File Uploads

You need an administrator-level user on both sites for export and import. If the form includes uploaded files, make sure those files are accessible at their current URLs and are not blocked by server redirect rules, Basic Auth, incorrect permissions, or remote storage that is not serving them correctly. GravityMigrate's changelog has specifically mentioned fixes related to source URL accessibility, redirects, and remote storage such as Amazon S3. That is not a reason to avoid file migrations, but it is a useful signal: always verify the "Uploads & Files" portion separately instead of relying only on a "Migration complete" status.

Another factor is ZIP size. The documentation does not present this as a large-scale server migration tool, and browser-based import can still be affected by hosting limits, PHP execution time, upload size limits, and connection stability. If the package includes many files or entries, do not close the import page until it finishes. If the process is interrupted by a network issue, current versions of the product can resume or cancel the import, but that is still an emergency path rather than the normal way to work.

Export: How to Build a Clean Migration ZIP Without Extra Clutter

After installing GravityMigrate on the source site, you start in the WordPress admin under the GravityKit menu and the GravityMigrate item. That page contains both export and import tools. When moving content to a new site, you start with export: select the forms, choose the related data, optionally limit entries, and download the ZIP file generated by GravityMigrate itself.

Selecting Forms

Do not start with "select all." Start with the actual migration goal. If you are moving a single GravityView directory, choose only the forms that power that directory. If you are moving a client application with nested participants, select the parent form and remember that the child form in Nested Forms is tied to the parent structure. GravityMigrate documentation for Nested Forms describes an important limitation: if the parent form includes a nested form, GravityMigrate identifies the related child form and exports it together with the parent form; exporting the parent without its attached child forms is currently not possible.

That behavior is helpful because it preserves the meaning of parent-child entries. If the child form were left behind on the old site, the new parent form would be incomplete. But it also requires attention when you review the package: sometimes the child form is used elsewhere too, and after import you need to verify not only the main form but the entire connected set.

Related Data: Entries, Uploads, Views, Feeds, Settings

After you choose the forms, GravityMigrate lets you include additional data types. For a simple form move without submission history, you can leave entries out. For a full migration of a working submissions database, entries are essential. For forms with file uploads, you need to include uploads, or the entries may survive while the file links become useless. For GravityView-based apps, you need Views and GravityKit Settings. For automations, you need feed configurations and workflow data when the corresponding add-ons are in use.

It helps to think in terms of the final outcome rather than "more data" versus "less data." A user opens the page, submits the form, the entry appears in the admin, the View displays it on the site, the workflow triggers approval, and the feed sends data to an external service. If you want to move that full chain, include every part of the chain. If you only need the form structure, leave entries and files out of the package. The best export is the one that matches the specific use case, not the biggest ZIP you can build.

Entry Date Range and Archive Password

The documentation shows that during export you can limit entries by date range and set a password for the generated export file. A date range is useful for staging-to-production moves: for example, you may want to move the structure and only recent test entries so you can verify Views and workflow without carrying over years of history. For a domain move, by contrast, you usually want the full set of entries, or the new site will only contain part of the record.

An archive password matters when the ZIP file contains personal data, documents, applications, payment fields, internal comments, or client files. The ZIP itself should not be sent through open channels, stored in shared folders without access control, or left on an administrator's desktop. If the data is sensitive, also restrict access to the test environment and delete temporary copies after verification.

Importing to the New Site: Order of Operations and Safe Initial Checks

GravityMigrate should already be installed and activated on the target site before you upload the ZIP. If the package includes GravityView, Gravity Flow, Nested Forms, Zapier, or other add-on data, those dependencies are best installed in advance. The import may bring over a feed or View configuration, but without the corresponding plugin WordPress will not be able to display or process that part of the interface the same way it did on the source site.

Uploading the ZIP and Choosing What to Import

The documentation describes the following path: open GravityKit - GravityMigrate on the new site, upload the ZIP, wait for the file to be processed, and then choose which forms and related data to import. That is helpful when one export package contains more data than the current site actually needs. For example, an agency might prepare a general package for a demo app but import only the forms and Views into a client site, leaving out the older test entries.

Before clicking Import, check three things. First, the file must be a ZIP created by GravityMigrate, not a CSV, JSON form export, or site archive. Second, the selected forms should match the current task, not an old test package. Third, the destination site should be ready to accept files: the upload directory must be available, no security rules should block the process, and the server must have enough upload and memory limits.

Why Import Creates Copies and How to Work With That

Non-destructive behavior is one of GravityMigrate's strengths. If the new site already has a form with the same name or a similar structure, the plugin should not overwrite it. It creates a copy instead. That reduces the risk of data loss, but it also creates a common post-import task: distinguish the old test form from the newly imported one, connect pages to the correct Views, and remove unnecessary duplicates only after verification.

The most reliable approach is to record the current IDs of forms, Views, and pages on the target site before importing. After import, compare the list. New forms and Views will receive new IDs, which means old shortcodes, manual links, custom code, or embeds may still point to the previous object. If a page is supposed to display the imported View, update the reference in the block, shortcode, or page setting. This matters especially with GravityView, where a View is tied to a specific form and set of entries.

What to Do After the Completed Status Appears

A successful import status means the process finished, but it does not prove that the business workflow actually works. After completion, open the Forms list, the Entries list for each imported form, the page with the View, and the feed settings and workflow status. At a minimum, test one form submission, one uploaded file, one View listing, and one external integration path if one exists.

If the process was interrupted, do not blindly rerun the same ZIP on production. First check what was already created: new forms, entries, uploads, Views. Modern versions of GravityMigrate support resume/cancel options for imports after a network error, but the right decision depends on the situation. On a test site, it is often easier to restore the backup and rerun cleanly. On a live site, it is safer to document what has already been created and only then decide whether to resume, cancel, or clean up manually.

Relationships You Cannot Afford to Lose: Views, Feeds, Workflows, Nested Forms, and Files

GravityMigrate delivers the most value when a form has long since stopped being just a form. In a real WordPress project, Gravity Forms often becomes the data source for a directory, client portal, workflow, mailing flow, CRM, payment flow, or internal reporting. In that situation, moving only the form fields is not enough.

GravityView Views

GravityView displays entries on the public-facing side of the site as searchable, sortable, or filterable Views. If you are moving a directory, member database, document library, client portal, or another GravityView-based interface, it is important to import not only the form and entries but also the View configuration. After import, verify that the View is connected to the newly imported form rather than the old ID, and make sure the page is using the correct block or shortcode.

There is also a presentation issue to keep in mind. Documentation for importing GravityKit app templates notes that GravityView inherits styles from the current WordPress theme, so the result on the new site may look different from the demo or the original site. That is not a migration error. If the data, fields, and View structure are intact but spacing, typography, or button styling looks different, check the theme, CSS, and layout settings.

Feed Configurations and External Services

Feeds in Gravity Forms are the settings that tell an add-on what to do with submission data: send it to a CRM, create a user, post to a webhook, trigger a payment flow, send it to Slack, or connect it to another service. GravityMigrate can move feed configurations, but the external service often needs to be verified separately. For example, GravityMigrate documentation for Zapier notes that Zapier feeds can migrate, but the Zaps themselves need to be adjusted on the Zapier side so they point to the new domain.

This is a typical responsibility boundary. The plugin moves the configuration inside WordPress, but it cannot automatically reconnect every third-party service if that service stores the domain, webhook URL, API credentials, or site identity on its own side. After import, review the feed list for each important form, open the external service, and run a test submission. Do not assume a feed is working just because it appears in the admin.

Gravity Flow Workflows

Gravity Flow adds multi-step workflow processes on top of Gravity Forms: approvals, user input steps, notifications, webhooks, status pages, and reports. GravityMigrate's official product page states support for Gravity Flow workflows, and Gravity Flow documentation shows that a workflow consists of the form, steps, assignees, notifications, and status behavior. That is why after the move you should verify not just the presence of the workflow, but also user permissions, email delivery, assigned roles, and status pages.

If the workflow on the old site was assigned to specific users or roles, those users may not exist on the new site, or they may have different roles. GravityMigrate should not be treated as a tool for synchronizing users and organizational structure. For a safe check, create a test entry, run it through one approval path, and confirm that the notification arrives, the step appears for the correct participant, and the final status matches expectations.

Nested Forms and Parent-Child Entries

Nested Forms by Gravity Wiz creates child entries linked to a parent entry. A typical example is a team application with multiple participants: the parent form stores shared information, and the child form stores the list of players. GravityMigrate documentation says that when you select the parent form, the plugin exports the attached child form as well, and exporting the parent without the child forms is currently not possible. That makes sense: without the child form, the parent entries would lose their context.

After importing that kind of package, check three places. Open a parent entry and confirm that the nested rows appear. Open the child form and verify that the child entries exist. Then submit a new test entry through the public form and add child records. If child rows do not appear, check that Gravity Wiz Nested Forms is installed, that the field settings are compatible, and that caching is not interfering, since Nested Forms relies on modal/AJAX behavior.

Uploaded Files

File uploads are often the most sensitive part of the move. Entries may contain links to resumes, documents, photos, contracts, or internal attachments. During migration, you need to enable Uploads & Files, verify that the source files are accessible, and then open several attachments on the new site after import. If the files live in remote storage, sit behind redirects, or are protected by server rules, the problem may be with source accessibility rather than GravityMigrate itself.

For verification, do not test only one small file. Open different file types: a PDF, an image, a document, a file from an older entry, and a file from a recent test entry. If the View displays a file upload field, test it on the public page as well. A migration in which entries were imported successfully but the uploaded files do not open is not complete from the user's perspective.

Practical Example: Moving an Application with GravityView and Workflow from Staging to Production

Let us look at a concrete use case. A staging site contains a form called "Vendor Application": a vendor submits information, uploads a certificate, the application appears in a GravityView directory for managers, and Gravity Flow starts an approval process. The goal is to move that complete setup to the live site without migrating all of WordPress and without rebuilding the form manually.

Goal

Bring the same working setup to production: a form with conditional logic, existing test entries, uploaded certificates, a GravityView View for reviewing applications, and a Gravity Flow workflow with approval steps. Existing production forms must not be overwritten because the site may already contain live forms for another project.

Preparation

1. WordPress, Gravity Forms, GravityKit GravityMigrate, GravityView, and Gravity Flow are installed on both staging and production.
2. Production has a backup of the database and uploads from before the import.
3. The administrator has recorded the IDs of the existing production forms and Views so the newly imported objects can be identified afterward.
4. File uploads have been checked on staging: a test PDF opens from the entry detail screen and from the View.
5. A private review page has been created on production so the imported View can be tested before publication.

Steps

On staging, open GravityKit - GravityMigrate and select the "Vendor Application" form. In the additional data options, include entries, uploads, GravityView Views, feed configurations, and Gravity Flow workflows. If there are too many test entries, limit the date range or keep only the records you actually need for verification. Set a password for the export file if the entries contain documents or personal data.

Download the ZIP and store it in a secure location. Do not rename the file in a way that breaks its connection to the task: in practice, it helps to include the environment and a short purpose in the filename, such as vendor-application-staging-to-production.zip. That is not a GravityMigrate requirement, just simple operational discipline that reduces the risk of uploading an outdated package.

On production, open the GravityMigrate page, upload the ZIP, wait for the package to be parsed, and choose the items you need. If production already contains a similar form, do not try to "update" it through import. Let GravityMigrate create a copy, then decide separately which object should become the primary one. After import, open the Forms list and rename the new form so the team can clearly see its status, for example "Vendor Application - migrated test."

Create or open the private review page and insert the imported GravityView View using the block or shortcode tied to the new View ID. Do not reuse the old shortcode from staging without checking the ID. If the View should only be visible to managers, review the role/capability rules and access settings.

Verification

Submit a new test application on production. Attach a small PDF or image to verify uploads. Open the entry detail in Gravity Forms and make sure the fields are populated, the file link opens, notes do not conflict, and the workflow status has started. Then open the View page and check that the new entry appears in the correct listing, search/filtering works, and the detail page link opens properly.

If the workflow includes approval, walk through one short path: a manager receives the task, changes the status, and the applicant receives a notification or sees the expected outcome. If there is a Zapier feed or another external feed, run a separate test trigger and make sure the external service points to the new domain.

Common Pitfall

The most common trap in this setup is confusion between staging IDs and production IDs. After import, forms, Views, and entries receive their own IDs on the new site. If a page, custom shortcode, support instruction, or external service still references the old ID, it may look like the migration "did not work" even though the data was imported correctly. The short takeaway is this: after import, always verify not just the data, but also the connections between pages, Views, feeds, and external services and the newly created objects.

Detailed Setup After Installation and Import

GravityMigrate does not have a long control panel full of fine-tuning options like a page builder. Its real configuration lives in the way you choose export/import contents and in how you verify the environment after the move. So the "best settings" here are not decorative toggles. They are a controlled procedure: matching versions of key add-ons, intentional data selection, separate checks for files and feeds, duplicate control, and a documented outcome.

The First Settings Worth Checking

After installation, open the product page under the GravityKit menu and make sure GravityMigrate is available to the user with the required permissions. Then confirm that the target site has the same functional add-ons that supported the form you are moving. If you are moving a View, check GravityView. If it includes workflow, check Gravity Flow. If it uses nested records, check Gravity Wiz Nested Forms. If Zapier feeds are involved, verify both the official Zapier Add-On and the external Zapier connection.

The second step is to review WordPress upload limits and PHP execution limits on the target site. You may be able to upload the ZIP in the GravityMigrate interface, but if the server upload limit is smaller than the file size, the import will never start. If the package is large, it may make sense to temporarily raise limits on staging or split the migration by forms, as long as doing so does not break dependencies. For Nested Forms, do not split parent and child forms artificially: the documentation explicitly states that they should travel together.

Which Options to Enable Only When Needed

Enable entries when you need submission history or test records for validating a View and workflow. If you are moving a single form without historical entries, you can leave them disabled. Include uploads only when entries with files are genuinely needed on the new site; otherwise the ZIP becomes larger and verification becomes more complicated. Include feed configurations when external integrations need to be restored, but after import be sure to disable or verify any feeds that might send real emails, create CRM records, or trigger webhooks.

GravityKit Settings and Views matter when you are moving not just a form, but the front-end layer of a GravityKit app. If the goal is to reuse the form as a draft and rebuild the View for a new theme, you can move only the form structure and selected entries. But if the View is already approved by the client, move it and test it as its own object.

How to Safely Disable Questionable Elements

After import on production, do not publish the public page immediately. Keep the imported View on a private page or in draft first. If a feed can send data outward, temporarily deactivate it until testing is complete. If a workflow sends notifications to real users, use a test record and warn the participants ahead of time. If duplicate forms appear, do not delete the old object until the new form has completed the full workflow successfully.

Rolling back a questionable setting should be simple: disable the feed, unpublish the page, remove only the imported test View, or restore the backup on staging. Do not try to fix the outcome by editing Gravity Forms tables directly. Official Gravity Forms documentation shows that the data is distributed across multiple tables, and direct operations without understanding the schema are risky.

Quick Verification Protocol

• The list of imported forms matches the selected set.
• Entries open in the admin and contain the expected fields.
• Uploaded files are accessible from the entry detail screen and from the View.
• The GravityView View shows the new entries and is not still pointing to the old form.
• Feeds do not send real data before testing is approved.
• The workflow starts on a test record and completes at least one expected step.
• Nested Forms shows child entries inside the parent entry.
• The public page uses the correct imported View or form embed.

How to Plan a Migration by Data Type, Not by Form Name

In a small project, it is easy to think the form is the whole product. In the Gravity Forms ecosystem, that is almost always an oversimplification. One form can be the entry point to a GravityView directory, the source of a workflow, a file submission gateway, a condition for user creation, a Zapier trigger, and part of internal reporting. That is why before exporting, it helps to describe the migration not as a list of form titles but as a data map: what entities are created, who uses them, where they appear, and what should happen after a new submission.

This approach is especially important in team environments. A developer may know that a View depends on a particular form, a manager may know that submissions must go into approval, and the site owner may know that applications should appear in a portal. If each person looks only at their own area, the export can easily end up incomplete. A short data map brings those expectations into one list that can be checked before import.

Forms and Field Structure

The form is the foundation of the package. It includes fields, labels, conditional logic, confirmations, notifications, submit settings, file upload settings, and depending on the add-ons in use, additional field settings. GravityMigrate is built to move Gravity Forms structure between sites, but after import it is still worth opening the form editor and checking critical fields. Pay special attention to fields with dynamic behavior: conditional logic, calculations, file upload fields, product/pricing fields, user registration fields, and nested form fields.

If the form uses custom CSS classes or page markup, the front-end appearance may differ because of the theme. That is not always a GravityMigrate error. Check whether the original form depended on CSS from the old theme, a page builder, or a shortcode wrapper. If so, the migrated structure may be correct even though the styling needs separate adjustment.

Entries and Supporting History

Entries are more than user responses. Around each record, Gravity Forms may store notes, payment status, created_by, user IP, timestamps, metadata, field values, file references, and add-on data. If you need the processing history for applications or submissions, moving entries is essential. If you only want to reuse the form on a new site, you can leave entries out. The mistake happens when a team includes entries "just in case" and then accidentally brings old test data into production, where it appears in a public View.

Before export, mark which entries are live, test, or archival. If a date range is officially supported, use it for staging packages. If you need the full history, decide in advance how you will validate the volume and integrity. You do not have to compare every record manually. It is enough to use control samples: a recent record, an older record, a record with a file upload, a record with workflow history, and a record with nested child entries.

Views and Public Pages

GravityView adds the presentation layer. A View may be embedded through a block, shortcode, or another page mechanism. After import, the View and the form may have new IDs, so an existing production page will not automatically start showing the new object if it was already connected to the old View. That is a perfectly normal reason for an "empty" outcome after what looked like a successful migration.

When planning the move, list not only the View title but also the pages where it is used. If the View displays private data, check the visibility rules and roles before publishing. If the View has search fields, filters, sorting, or a Single Entry layout, test each feature using a sample record. A View should only be considered migrated when the user-facing page works, not when the object merely appears in the Views list.

Feeds, Workflow, and External Dependencies

Feeds and workflows should be planned separately from the form. A feed may send data to a service, create a user, post to a webhook, or perform some other add-on action. A workflow may assign a task to a specific user, role, or email address. On the new site, those relationships may require a new API key, fresh authorization, a different email routing setup, or an updated domain in the external service.

A good practice is to separate the migration into "data import" and "external activation." First import the form, entries, Views, and workflow, but do not trigger real external actions yet. Then review the feed settings and only after that enable live outbound data flow. This is especially important for CRM, help desk, Slack, Zapier, payment-related feeds, and any automation that creates real records for a client.

Files and Privacy

Files need their own plan because they often contain personal documents. If the site accepts resumes, contracts, medical documents, coursework, participant images, or any other private attachments, then the ZIP migration becomes an operation involving sensitive data. A password on the export file helps, but it does not replace access control for staging, temporary archives, or the people who can download the package.

After migration, remove temporary ZIP files from shared folders, clean out unused test uploads, and confirm that the public View does not expose files to users who should not see them. With file fields in particular, it is important not to confuse "the administrator can open the file" with "the correct role has access to the file." Those are different checks.

Special Cases: Multisite, Demo Apps, and Partial Migrations

The official product page states support for WordPress multisite, and GravityKit documentation shows demo-to-live use cases built around GravityMigrate. These cases resemble a standard migration, but they involve more organizational detail. The more sites and repeated packages you manage, the more important it is to keep an import log: where the ZIP came from, which forms were selected, where it was imported, who verified the outcome, and what was disabled after testing.

WordPress Multisite

In multisite, it is especially easy to make a mistake with site context. One network admin may have access to several subsites, but Gravity Forms data and GravityKit objects belong to a specific site within the network. Before exporting, make sure you are in the correct subsite admin. Before importing, make sure the target subsite has the required plugins active and configured.

If the network uses shared users, roles may differ between subsites. Workflow assignment, View permissions, and form capabilities need to be checked separately on the target site. Do not import the package into the main network site just because GravityMigrate is installed there. In multisite, "Which site am I on right now?" should be the first line on the checklist.

Importing a GravityKit Demo App

GravityKit documentation describes a workflow in which a user downloads a demo app ZIP and imports it into their own site through GravityMigrate. That package may include forms, entries, Views, pages, feeds, uploads, and files. It is a convenient starting point for a quick prototype, but after import you should not treat the demo as a production-ready application. You still need to replace test entries, review permissions, update copy, disable unnecessary feeds, and adapt the page to the theme.

Check the front-end presentation separately. GravityKit documentation warns that Views inherit styles from the WordPress theme. If the demo looks different on your site, separate functional validation from design review. Functionally, what matters is that the form submits, the View shows records, the files open, and the workflow and feeds work. Design can be refined later through the theme, GravityView settings, or safe CSS.

Moving Things in Stages

Sometimes it is tempting to move a large project in several packages: forms first, then entries, then Views. That can make sense if the setup is large and you clearly understand the dependencies. But it is risky when forms are tied together through Nested Forms, workflow, or Views. For example, a parent form without its child form is not a complete outcome, and a View without entries simply looks empty.

Before doing a staged migration, ask one question: can each package be validated as a complete outcome after import? If not, it is better to combine the elements into one export. If yes, document the order: first the base form structure, then entries and files, then Views and pages, then feeds/workflows and external checks. After each step, create a control submission or open the View so you are not trying to diagnose the whole project at once.

Repeat Migration After Fixes on Staging

A common situation looks like this: the team imports a form into production, finds an issue on staging, fixes it there, and wants to move it again. Because GravityMigrate does not overwrite existing forms, a repeat import creates another copy. That is safe, but it requires discipline: rename the outdated copy, update the page to the new View/form ID, and remove the old one only after final testing.

For repeat migrations, it helps to keep a simple project changelog: which ZIP was imported, which forms appeared, which pages were reconnected, which feeds were disabled or enabled, and which test entries were created. This is not bureaucracy. When several similar forms appear on a site, that log saves hours and reduces the risk of deleting the wrong object.

Validating the Outcome: How to Know the Migration Is Really Finished

Validation should follow the user's workflow, not a list of database tables. If you moved an application flow, test the application flow. If you moved a directory, test the filters, sorting, detail page, and access permissions. If you moved a workflow, test task assignment, email delivery, and the final status. That is the only way to catch problems that do not show up on the "import complete" screen.

Public-Facing Side of the Site

Open the page with the form in a private browser window. Fill in the required fields, go through the conditional logic, upload a file, and submit the form. If the form uses AJAX, make sure the confirmation message appears without hanging. If the page is cached, temporarily exclude it from cache or clear the cache after import, especially if the View or a nested modal behaves strangely.

For GravityView, open both the Multiple Entries view and the Single Entry view if one exists. Check search, filters, sort order, pagination, field labels, links, edit entry permissions, and visibility rules. If the View looks different, compare not only the migration but also the theme: CSS, layout width, block styles, and page template settings.

Admin Area

In the admin area, review form settings, notifications, confirmations, entries, feeds, and workflow. Open several older imported entries and one new test entry. If the older entries contain files, confirm that the links point to the new site or are being served correctly by the new storage. If the records include private notes, make sure they have not become public through the View.

For feeds, do not stop at confirming that they exist. Open the specific form, go to the add-on feed settings, and review the mapping. If the feed depends on an external account, open the service itself. In the case of Zapier after a domain move, check the connection and the domain inside the Zap, because GravityMigrate documentation specifically states that the destination website domain in Zapier needs to be updated.

Before-and-After Comparison

Before the migration, it is useful to make an expectation table: how many forms, how many entries, which Views, which files, which workflow steps, which feeds. After import, fill in the "actual outcome" column. You do not need a mathematical match for every internal ID: IDs can be different on the new site. What matters is that the meaning and the working behavior of the full chain are preserved.

Primary check: a new test record should follow the same path on the new site that a record follows on the source site: form - entry - file - View - feed or workflow - final status.

How to Use GravityMigrate Alongside Other Gravity Forms and WordPress Tools

GravityMigrate does not need to solve every migration problem. It becomes more useful when you clearly separate its role from the roles of GravityImport, GravityExport, WP Migrate, Duplicator, and similar tools. A well-structured migration approach usually includes several layers: a full-site backup, a WordPress environment migration, a Gravity Forms package migration, and a separate import of outside data.

GravityImport for CSV and External Sources

If you have a CSV from an old CRM, a spreadsheet, or another form plugin, GravityImport is closer to the task. It handles column mapping, can import entries, and in some cases can create a form from the CSV structure. GravityMigrate will not help here because it is not designed to turn an arbitrary table into a Gravity Forms data structure.

A combined workflow looks like this: first use GravityMigrate to move the working Gravity Forms environment with forms, Views, and settings, then use GravityImport to load additional outside entries if they come from CSV. After that, verify that the View displays both the migrated and the newly imported data correctly.

GravityExport for Reports and Verification

GravityExport and native export tools are not meant for moving an entire environment. They are used to export entries to CSV, Excel, or other formats. They are useful both before and after migration: you can export a control sample of records from the old site, repeat the export after import, and compare whether the key fields are still there. This is especially helpful for accounting, education, and application-based projects where the historical submissions matter as much as the form itself.

Full-Site Migration Plugins

WP Migrate, Duplicator, and All-in-One WP Migration handle a broader layer: the WordPress database, files, themes, plugins, uploads, and domain replacement. If the task is to move the entire site, one of those tools may be the main solution. GravityMigrate becomes useful when you are moving a specific Gravity Forms setup or when a full site migration would be too broad for the current task.

A typical agency workflow might look like this: Duplicator moves the entire staging site to a new host, and then GravityMigrate is used afterward for a separate update of several Gravity Forms applications between staging and production. In that approach, it is important not to duplicate work: if the whole site has already been moved in full, importing the same GravityMigrate package again can create duplicate forms and Views.

Common Migration Problems and How to Diagnose Them

Most GravityMigrate problems are not caused by the import button itself. They usually come from the environment: a missing add-on, the wrong ZIP, inaccessible files, old IDs, outside services, caching, or an untested production import. Below is a practical symptom-based troubleshooting guide.

The ZIP Is Rejected or the Import Will Not Start

Symptom: the file does not upload, the interface reports an unsupported format, or the process stops before you can choose the data. Possible causes include selecting the wrong file, using a ZIP not created by GravityMigrate, a package that exceeds the upload limit, a corrupted file, or an interrupted browser/server upload.

Check the file origin: it should be an export package created by GravityMigrate on the source site. A CSV entry export, JSON form export, Duplicator archive, or full WordPress backup will not work. If the file is correct, review the size and hosting limits. For sensitive data, recreate the export, download it again, and avoid sending it through services that may alter the archive.

Duplicate Forms Appeared After Import

Symptom: two similar forms appear in the Forms list, while the site page still shows the old one. The reason is often normal: GravityMigrate creates a copy and does not overwrite existing forms. That behavior is safe, but it requires you to reconnect the page to the new form or View manually.

Check the ID of the new form, open the page, review the Gravity Forms block or GravityView shortcode, and make sure the correct object is being used. Do not delete the old form immediately if it is still receiving live entries. First create a test submission in the new form, verify the View and the feed, and only then decide which form to keep.

The GravityView View Imported but Shows an Empty List

Symptom: the View exists in the admin, but no entries appear on the page, or the wrong data set is shown. Possible causes include the View still being tied to the old form, entries not being included in the export, a View filter hiding the records, insufficient user permissions, or the page still using the old shortcode.

Open the View settings and check the connected form, then review the Entries list for the new form. If entries are present, review filters, approval status, and access restrictions. If entries are missing, go back to the export options: you may have moved only the form structure. For a repeat migration, staging is the safer place to test so you do not create extra copies on production.

Uploaded Files Will Not Open

Symptom: the entry was imported, but the file link leads to an error, a blank page, or the old domain. Possible causes include the Uploads & Files section not being selected, inaccessible source files, storage using redirects, S3 or another remote storage, or the server blocking access to private uploads.

Check whether file transfer was included. Then open the source file on the old site as an administrator and, if appropriate, without special cookies. If the source URL is not accessible, resolve the storage accessibility issue first. After import, test files from different entries and do not forget to clear cache on the View page if the link is displayed through a public layout.

Zapier or Another External Feed Is Visible but Not Working

Symptom: the feed is present in Gravity Forms, but the external service does not receive new submissions. For Zapier, GravityMigrate's official documentation states that after a domain move, Zaps must be updated on the Zapier side. Other services follow the same general pattern: the domain, webhook URL, API connection, or account authorization may be stored outside WordPress.

Check the feed inside the form, then open the external service and run a test event. If you have to choose between temporarily disabling the feed and sending real data, choose disabling it until verification is complete. On production, add a test record with clear sample data so it can be removed later or easily distinguished from a real submission.

The Workflow Does Not Assign the Task to the Correct User

Symptom: the entry is created, but the approval step does not appear for the manager, or the notification is not sent. Possible causes include the matching user not existing on the new site, the role name being different, email delivery not being configured, Gravity Flow not being active, or the workflow step being imported while the required status page is still unpublished.

Check that Gravity Flow is installed, then review the workflow steps, assignees, roles, and email delivery. If the workflow was tied to specific user IDs, those IDs will almost certainly be different on the new site. Reconfigure the assignment using roles or existing users and run a test entry all the way to the final status.

The Import Hung or Was Interrupted

Symptom: progress never reaches completion, the browser loses connection, or a server error appears. GravityMigrate's changelog shows that the product has received improvements around resume/cancel import behavior and network failures. Even so, in real work you should avoid closing the page during import and avoid immediately rerunning the import on top of an unclear state.

On staging, it is usually easier to restore the backup and rerun the import with a smaller package or better limits. On production, first document what has already appeared: forms, entries, Views, files. If the interface offers resume or cancel, choose deliberately. If the cause looks like a hosting limit, it is better to retry in an environment with higher memory, upload, and execution time limits.

When GravityKit GravityMigrate Is the Right Choice

GravityKit GravityMigrate is worth using when you already have a working Gravity Forms environment and need to move it as a connected product bundle: forms, entries, files, Views, feeds, settings, workflows, and nested structures. It is especially useful for staging-to-production moves, domain changes affecting only part of a project, copying a GravityKit demo app, and agency-style repeat deployments of configured forms.

The plugin does not replace a backup, does not move data into another form plugin, is not a universal CSV importer, and does not remove the need to verify external services. Its strength lies elsewhere: it reduces the amount of manual work when a form is tied to entries, files, GravityView, Gravity Flow, Nested Forms, and feeds. If you understand that boundary, the product can move a complex setup far more cleanly than rebuilding it by hand.

Before using it in a live workflow, follow a short path: prepare a backup, verify dependencies, run a test export, import the ZIP into staging, validate the user workflow, and only then move on to production. After that, you can download the GravityKit GravityMigrate package and perform a controlled migration on your site.

The final benchmark is simple: a new test record should behave on the new site exactly as it did on the old one. It should be submitted through the form, appear in entries, open its files, show up in the View, trigger the correct feed or workflow, and require no manual database edits. If that is true, the migration is genuinely complete.