Migrating forms with AI using the GravityKit MCP

GravityMigrate 2.1 and later can run your migrations through an AI assistant, such as Claude. Connect the assistant to your site with the GravityKit MCP, then say what you need, for example “Do a dry run of moving my WPForms forms into Gravity Forms.” Each of these migrations can also be run from the GravityMigrate screen or with WP-CLI.

Things you can ask for #

Once the connection is in place, you can ask the assistant to:

• Move forms between Gravity Forms and Contact Form 7, Fluent Forms, Formidable Forms, Forminator, Ninja Forms, WPForms, or WS Form, in either direction, with a dry run first that shows what each field becomes.
• Export Gravity Forms forms with their entries, Views, and other data to a migration file, and find the finished file.
• Read a migration file before importing it, then import it.
• Report whether a migration is running and how far along it is, stop one, or clear one that is stuck.

The assistant works on the site the GravityKit MCP is connected to. It can export a migration file on one site and import it on another, but it can’t move the file between them. You download the file and put it on the destination server yourself.

The tools that import a migration file and clear a stuck migration stay off until you allow them. Allowing the import and reset tools explains why and how.

Before you start #

Make sure you have the following in place:

• GravityMigrate 2.1 or later, with Gravity Forms active.
• WordPress 6.9 or later. GravityMigrate’s AI tools are built on the WordPress Abilities API, which arrived in WordPress 6.9. On an older version, the GravityMigrate screen and WP-CLI still work, and the assistant gets no GravityMigrate tools.
• The GravityKit MCP connected to your site with an application password. Getting started with GravityKit MCP covers the setup, including the Claude Desktop extension.
• An administrator account. Migrating needs full administrator access (the manage_options capability), whether it runs from the GravityMigrate screen, WP-CLI, or the assistant, so the application password has to belong to an account that has it.
• For a migration between form plugins, the other plugin installed and active on the same site.
• For exports and imports, a site that can run background jobs. Background processing explains what a site needs for that.

Check that the tools are there #

Ask the assistant “Which GravityMigrate tools do you have?” Their names start with gmig_, such as gmig_platforms_list and gmig_migration_analyze, and the GravityKit MCP tools reference describes how the tool list is built. If none appear, check the versions above, then ask the assistant to reload abilities so it reads your site’s tools again.

Moving forms between form plugins #

This is the migration described in Migrating forms from another form plugin, run by the assistant. It creates a new form in the destination plugin and leaves the original as it was. The fields, conditional logic, confirmations, and notifications move with the form where the destination plugin supports them, and the entries stay in the plugin they were submitted to. Gravity Forms is always on one side of the migration.

1. Ask which form plugins GravityMigrate can migrate on this site. The answer gives each plugin a yes or no for each direction, with the reason a direction is unavailable, such as the plugin not being active on the site.
2. Ask for a dry run, for example “Do a dry run of moving my Ninja Forms forms into Gravity Forms.” The assistant lists the forms and reports what each field becomes and what happens to it, such as “Stays the same” or “Becomes the form’s submit button.” The report also names any warnings and the add-ons the new form needs. A dry run writes nothing.
3. Read the report, then tell the assistant which forms to migrate. The answer includes each new form’s ID and a link to edit it.

A request covers up to 25 forms, so ask for a larger set in batches. A migration between form plugins finishes within the request, with no background job to wait for.

When a form was migrated into Gravity Forms before, the dry run says so and names the Gravity Forms form it created then. Running the migration again creates a second copy, and the first one stays as it is. To leave such forms out, ask the assistant to skip the forms it already migrated. Each one is then listed as skipped, with the form it became.

Ask the same way when you retry a migration that timed out or stopped partway, so no form is created twice. A form whose earlier run stopped partway is skipped too and listed as unconfirmed, because a new form may exist for it without being recorded. Check the destination for that form before you migrate it again without skipping.

A migration the assistant requests while another assistant migration is still running on the site is refused. The assistant is told to wait for the first one to finish, then ask again with the forms already migrated left out.

To move forms between two other plugins, run two migrations: into Gravity Forms first, then out to the destination plugin. What each plugin loses on the way is listed on its own page, such as Migrating between Ninja Forms and Gravity Forms.

Moving forms and entries to another site #

A migration file holds Gravity Forms forms and their data for a move from one WordPress site to another. It is the same file the GravityMigrate screen creates, as Getting started with GravityMigrate describes, and the assistant’s tools call it a bundle.

Step 1: Export from the source site

Connect the assistant to the site you are moving from and ask for the export, for example “Export the Business Directory form to a migration file.” Unless you ask for something else, the file includes the forms with their entries, their Views, and the pages that embed them.

Uploaded files are left out unless you ask for them, so mention them when your forms collect files. You can also ask for form revisions, add-on feeds, Gravity Flow history, and entry drafts. An export can be limited to entries from a date range, or cover every form on the site, including inactive and trashed forms.

The file can also include Gravity Forms settings, GravityKit settings, and REST API keys. They can contain API keys and credentials, such as a map service key, so ask for them only when you are moving the whole site’s configuration.

The export runs as a background job, and the assistant checks on it until it finishes. Only one export runs at a time.

Step 2: Download the file

When the export is done, the assistant finds the file and gives you its download link. Download it soon: by default, GravityMigrate deletes exported files from the server about three hours after the most recent export. The file holds data from your site’s database, so treat the link like a password and don’t post it anywhere it would be stored, such as a support ticket.

When you ask for uploaded files, the migration file records where each one lives, and the destination downloads it from the source site during the import. The source has to stay online and reachable for that. When the source is a local site, is behind HTTP authentication, or is about to be shut down, ask the assistant to include the files inside the migration file instead. The file gets larger. Packaging has a total size limit, so some files can still be left out, and the import downloads those from the source as before. Where uploaded files go during a migration has the details.

Step 3: Put the file on the destination server

Upload the file to the destination site’s server the way you usually move files there, such as with SFTP or your host’s file manager. Put it in the gk-uploader folder inside the site’s uploads folder (create the folder if it isn’t there), and note the file’s full path, for example /home/youraccount/public_html/wp-content/uploads/gk-uploader/migration.zip. The assistant reads only .zip files in that folder or in the folder GravityMigrate saves its own exports to, and refuses a file anywhere else.

If you would rather import from the GravityMigrate screen, upload the file there instead, as Getting started with GravityMigrate describes.

Step 4: Check what the file contains

Connect the GravityKit MCP to the destination site with an application password from an administrator account there. The steps are the same as for the source, in Getting started with GravityKit MCP. Then ask the assistant to inspect the file at its path.

Inspecting writes nothing. The answer lists the forms in the file, with their IDs on the source site, the kinds of data it holds, and the site it came from. It also says whether the database data inside the file fits the destination’s import limit, and whether the uploaded files were packaged into it, with counts of those included and left out. A file stored outside the source site’s uploads folder is counted in neither, so check a few imported files before you shut the source site down.

The answer also says whether the source site’s address is one the import can download from. That check looks only at the address, which has to be public rather than private or local. It does not test the downloads, so a source behind a login or a firewall can still fail.

Step 5: Import the file

Ask the assistant to import the file. The import tool is off until you allow it, as Allowing the import and reset tools explains.

Forms, entries, Views, and pages are created alongside what the destination already has, each with a new ID, and What changes when you import explains the renumbering. Gravity Forms settings and GravityKit settings replace the destination’s own, and REST API keys are added to its keys, so importing them changes the destination site’s own configuration.

You can import the whole file or only some of its forms or kinds of data. Name forms by their IDs on the source site, as the inspection listed them. Importing the same file again creates another copy of its forms, entries, Views, and pages, and writes its settings over the destination’s again.

The import runs as a background job. When it finishes, the assistant can report what it moved, with a link to each new form.

Checking on a migration #

Ask the assistant whether a migration is running. It reports a running export or import and what the last finished import moved. For an import, it also reports progress and the time left in the current stage when it has an estimate, and those figures start again at each stage. A migration between form plugins never shows in that report, because it finishes within its own request.

Ask it to stop an export or import, and it cancels the background job. An import stopped partway leaves on the site whatever it had already written, and the answer names the kinds of data it wrote.

A new import is refused while an earlier one is running, stuck, or crashed. An import that hasn’t moved for a while may be in one long step, so ask again a couple of minutes later before treating it as stuck.

To clear a stuck or crashed import, the assistant uses the reset tool, which is off until you allow it. The reset cancels every GravityMigrate background job on the site, exports included, and clears the site’s import and export state, so check that nothing else is running first. The tool refuses to run until you confirm, because it also throws away the record of the crashed import, which is the only description of what that import half-wrote. Forms and entries that earlier migrations created stay, and so do finished migration files.

Allowing the import and reset tools #

The GravityKit MCP keeps destructive tools off until you allow them. GravityMigrate has two: gmig_bundle_import, because an import can replace the destination’s settings and cannot be undone, and gmig_state_reset, because it throws away a crashed import’s record. Until you allow them, both appear in the assistant’s tool list marked as disabled.

To allow both, add gmig to the GRAVITYKIT_MCP_ALLOW_DESTRUCTIVE setting in the env block of your configuration file:

"GRAVITYKIT_MCP_ALLOW_DESTRUCTIVE": "gmig"

"GRAVITYKIT_MCP_ALLOW_DESTRUCTIVE": "gmig"

With gmig as the only value in that list, GravityView’s destructive tools stay off. The Gravity Forms delete tools are governed by GRAVITY_FORMS_ALLOW_DELETE and stay as you set them. To allow only the import, use gmig_bundle_import instead of gmig.

In the Claude Desktop extension, enter gmig in Allow only some destructive tools (optional). It works with Allow Claude to delete and overwrite your data unchecked. Destructive product tools describes both settings in full.

Troubleshooting #

• The assistant has no GravityMigrate tools. Confirm GravityMigrate 2.1 or later and WordPress 6.9 or later, then ask it to reload abilities.
• The assistant says the site can’t run background jobs. Exports and imports need them, while a migration between form plugins doesn’t. Background processing explains what a site needs, and the GravityMigrate screen and WP-CLI can run the same migration without background jobs.
• The assistant says the account needs full administrator access. The application password belongs to an account without it. Create an application password on an administrator account and update the connection.
• A form plugin gets a no in both directions. The answer gives the reason, usually that the plugin isn’t active on the site. Activate it, then ask again.
• The import is refused because an import is running, stuck, or crashed. See Checking on a migration.
• A migration is refused because another one is running. Wait for the first to finish, then ask again and have the assistant skip the forms already migrated.
• The assistant says there is no file it can read at that path. Move the file into wp-content/uploads/gk-uploader on the destination site, as in Step 3, and give the assistant the new path.
• The migration file is gone from the source site. By default, exported files are deleted about three hours after the most recent export. Ask for the export again.
• Uploaded files arrive as broken links. The destination couldn’t download them from the source site. Export again with the files included, and see Where uploaded files go during a migration.
• The import tool is disabled. See Allowing the import and reset tools.

Related articles #

• Creating Views with AI using the GravityKit MCP