Migrating forms from another form plugin

GravityMigrate can recreate the forms of another form plugin as Gravity Forms forms, and can copy Gravity Forms forms into another plugin, without leaving the site they are on. It works with Contact Form 7, Fluent Forms, Formidable Forms, Forminator, Ninja Forms, WPForms and WS Form. This article covers that kind of migration, in both directions, and explains the report GravityMigrate shows for each form before it runs. Moving a whole Gravity Forms setup to another WordPress site is a different job, covered in Getting started with GravityMigrate.

What moves, and what stays where it is #

A plugin migration moves the form: its fields, their settings, the conditional logic, the confirmations and the notifications. It creates a new form in the destination plugin and leaves the original untouched, so you can compare the two and delete the old one when you are ready.

It does not move submissions. The entries people sent through a Contact Form 7 or WPForms form stay in that plugin, and a Gravity Forms form copied into another plugin leaves its entries, uploaded files, Views and settings behind in Gravity Forms. Entries travel only between two Gravity Forms sites, through a migration file.

Gravity Forms is the hub. A migration always has Gravity Forms on one side: another plugin’s forms come into Gravity Forms, or Gravity Forms forms go out to another plugin. To move forms between two other plugins, run two migrations: bring the forms into Gravity Forms first, then copy them out to the destination. Gravity Forms has to be installed and active on the site throughout.

Before you start #

Install and activate Gravity Forms and GravityMigrate on the site.
Have the other plugin installed and active on the same site, with its forms in place. The migration reads them from the site; there is no file to export from the other plugin first.
When a form uses a feature the destination plugin sells separately, such as signatures or payments in WPForms, have that add-on ready. The migration tells you which ones it needs before it runs. The free editions of Fluent Forms and WS Form cannot create some field types, and the report names each field that needs the paid edition.

Bringing forms into Gravity Forms #

Go to GravityKit, then click GravityMigrate, and click Import into Gravity Forms.
On the Source step, the right-hand column lists every form plugin on the site with how many forms it holds. Click the plugin you are moving from.

The Source step of an import, listing the form plugins on the site and how many forms each one holds

On the Choose Forms step, tick the forms to bring in. Every form has its own card, and Show what happens to each field opens a table with one row per field. Each row names the field as the other plugin names it, what it becomes in Gravity Forms, and whether it stays the same, changes shape or is left out. Anything the migration cannot carry is listed on the card before you continue, so nothing is dropped without being named. The wording is explained under Reading the report below.

The Choose Forms step of an import from Contact Form 7, with the field table open for the sample contact form

The Confirm step lists the forms and their source. Click Import.

The Review what will be imported step, with one form from Contact Form 7 and the Import button

The Done step names each form that was created, with a link to open it in Gravity Forms, and says whether it arrived with its confirmations and notifications.

The Import complete step, with the new Gravity Forms form linked and marked as added with its confirmations and notifications

Running the same migration again creates a second copy of the form. The card warns you when a form has been imported before.

Copying Gravity Forms forms into another plugin #

Go to GravityKit, then click GravityMigrate, and click Export from Gravity Forms.
On the Where step, the right-hand column lists the form plugins on the site. Click the one you are copying into. (The GravityMigrate file card on the left is the site-to-site move, which creates a file instead.)
On the Choose Forms step, tick the forms to copy. Each card lists what changes on the way, under Modifications, and what to set up in the other plugin before the form goes live, under Before you use the form, with the same per-field table beneath.

A form's card on the Choose Forms step of an export to WPForms, listing its Modifications and what to set up before using the form

The Confirm step counts the forms and names the destination. Click Recreate to run the migration.
The Done step links each new form in the other plugin. Your Gravity Forms forms, their entries and their files stay exactly as they were.

The Done step of an export to WPForms, with the new form linked and marked as added with its confirmations and notifications

Reading the report #

Both directions show the same report on the Choose Forms step, one card per form, before anything is written. A card carries up to three lists, and each list appears only when it has something to say. Beneath them, Show what happens to each field opens the field table. The command line prints the same report when you run a plugin migration with --dry-run.

The three lists on a card

Won’t migrate names each field that has no counterpart in the destination plugin. The wording is always the same shape: a field “is a Signature field, which has no Contact Form 7 field equivalent. It will be skipped.” The rest of the form still migrates.

Modifications names what comes across in a changed shape. A name field sent to WPForms, for example, is reported as “A WPForms name field words its own sub-labels, so those were not carried; the placeholders were.” The field exists on the other side, and this list says how it differs.

Before you use the form names what the destination plugin needs from you before the form is published. These are settings the migration cannot make for you, such as WPForms’ upload settings and storage permissions for a file upload field, or CAPTCHA keys.

The field table

The table has three columns. The first names the field as the source plugin names it, with the field’s label and type. The second names what it becomes in the destination, followed by Required when the requirement carries across. The third, What happens, uses one of these phrases:

Phrase	Meaning
Stays the same	The field is the same kind of field on both sides.
Becomes …	The field arrives as a different kind of field, named the way the destination names it: “Becomes a dropdown list”, “Becomes a paragraph of text”, “Becomes a checkbox list”.
Becomes the form’s submit button	The source treats the submit button as a field; the destination does not.
Becomes text on the form and Becomes a page of the form	Content the source stored as a field, such as an HTML block or a page break, arrives as part of the form rather than as a field.
Combined with another field	Several source fields make one destination field. Two Contact Form 7 name inputs become one Gravity Forms Name field, for example, so a seven-field form produces six rows.
Added to the form	A field the destination adds that the source never had.
Not migrated	The field will not exist on the other side. The reason is in the card’s Won’t migrate list.
Can’t move — skipped	The destination refused the field outright, a CAPTCHA sent to Contact Form 7 for example, and it was left out.

A notice above the table tells you when the same source form was migrated before: “This Contact Form 7 form (#4) has been imported before into Gravity Forms form #4. A new form will be created.” A migration never updates a form it created earlier; it makes a new one.

Settings that were not read

A sentence such as GravityMigrate did not read the date format for “Event date” from Contact Form 7, so Gravity Forms will read every date as mm/dd/yyyy. means a setting on the source field was not carried, so Gravity Forms falls back to its own default. The same sentence covers a date field’s calendar picker, a time field’s 12-hour or 24-hour clock, a number field’s decimal format, and a phone field’s format. The field itself arrives, and only that setting needs checking.

What the Done step says

Once the migration runs, the Done step lists each form that was created with a link to open it in the destination plugin. A form that lost nothing reads “Added, with its confirmations and notifications.” A form that lost a field reads “Added with its confirmations and notifications. Skipped Signature, because Contact Form 7 has no equivalent.”

What to expect from each plugin #

Contact Form 7 holds the least of a Gravity Forms form: no conditional logic, no multi-page forms, no time or password fields, and no entry limit, login requirement or honeypot setting. A form arriving from Contact Form 7 has no spam protection until you set some up in Gravity Forms, because reCAPTCHA lives in Contact Form 7’s own settings. An acceptance box that was inverted, where ticking it meant refusal, arrives as an ordinary consent box and needs rewording.
Fluent Forms holds most field types, surveys and Likert grids included. Its chained selects keep their options in an uploaded CSV file, so that field arrives as an empty dropdown to fill in. Without Fluent Forms Pro some fields, phone among them, are exported as the nearest free field or not at all, and the report says which.
Formidable Forms: a read-only field becomes editable in Gravity Forms, which has no read-only field, and a Simply Schedule Appointments booking field arrives as a date, so the date is asked for but no appointment is booked.
Forminator holds multi-page forms, entry limits and login requirements, and signatures with its Pro e-Signature add-on. A Gravity Forms order total becomes a Forminator calculation, so check its formula against the priced fields.
Ninja Forms has no website field, so a Website field becomes plain text, and no multi-page forms. A Ninja checkbox that stored custom wording records 1 instead once in Gravity Forms. Going out, Ninja Forms allows one unique field per form, so the first field set to refuse duplicates is carried and any others accept duplicates.
WPForms holds the most of a Gravity Forms form, repeaters with their inner fields and rank, rating, Likert and survey fields included. A WPForms date and time field arrives as a date only, and a Gravity Forms confirmation with conditions is not exported, because WPForms would show it to everyone. Signatures, payments, surveys, rich text and repeaters need WPForms add-ons or WPForms Pro, and the report names them.
WS Form keeps multi-page forms as groups. A conditional rule that mixed “and” with “or” arrives as “any”, so check it. A consent field sent to WS Form becomes a legal field, which shows the terms but does not record acceptance, so add a checkbox beside it if you need proof. Without WS Form PRO some fields are not created, and the report says which.

Two field types are worth knowing about across the board. Repeater fields keep their inner fields only in WPForms and Forminator. Fluent Forms turns those inner fields into text boxes, Ninja Forms keeps the group and drops them, and the rest have no repeater at all. Signature fields travel to Forminator, WPForms and WS Form only.

A reference page for each plugin #

Every field type, form setting and merge tag is listed per plugin, in both directions, on its own page. Those tables are generated from the migration code, so they follow the plugin as it changes.

From the command line #

The same migrations run over WP-CLI, one form at a time, with wp gk migrate to <plugin> and wp gk migrate from <plugin>, and --dry-run prints the report described above without changing anything. Migrating Gravity Forms from the command line with WP-CLI has the commands.