What changes when you import

A migration file recreates your forms, entries and Views on the new site. The new site numbers them its own way, and it never folds them into forms that are already there. This article explains what an import creates and what it renumbers. It also covers which references GravityMigrate rewrites for you, which ones you update yourself, and how to repeat a migration.

An import always creates new forms #

Every form in the file becomes a new form on the site, and every entry in the file becomes a new entry inside that form. GravityMigrate never looks for an existing form to update, merge into or top up, and it never matches an incoming entry against one that is already there. Views, pages and add-on feeds arrive as new copies too, pointed at the new forms.

A form whose title is already taken gets a numbered title, so a second “Contact us” arrives as “Contact us (1)”. Importing the same file twice therefore gives you two copies of every form, not one form with twice the entries. When the file was exported from the very site you are importing into, the wizard says so before you continue: “This file was exported from this same site. Importing it adds a second copy of every form you select. It does not update or replace the ones already here.”

What is renumbered #

Field IDs stay the same, so conditional logic, calculations, merge tags such as {Name:1.3} and field-level settings keep working without any rewriting. Each imported entry keeps a record of the IDs it had on the old site, and each imported form keeps its old form ID in its settings, so a migration can always be traced back.

What GravityMigrate rewrites for you #

Because the form and entry IDs change, GravityMigrate updates the references it knows about so the imported pieces still fit together:

• Views. The form a View is built on, the joins between forms, and every form ID inside the View’s field and widget configuration are updated to the new form IDs. A View whose form is not in the migration file is left pointing at no form rather than at whatever form happens to have that ID on the new site.
• Add-on feeds referenced by View widgets, such as a chart widget, are updated to the new feed IDs.
• Pages and posts in the migration file. Their shortcodes are updated: [gravityform id=], [gravityview id=], [gv_entry_link], [gvfield], [gventry] and [gravitycharts id=]. So are the Gravity Forms, GravityView and GravityCharts blocks, with their form, View, entry and chart IDs.
• Nested forms. A Gravity Wiz Nested Forms field is pointed at the new ID of its child form.
• Gravity Flow. The workflow steps stored on each entry and the activity log are updated to the new step and entry IDs.
• Entries linked to posts. An entry that created a post keeps the link when that post is in the file, and loses it when it is not.

What you update yourself #

Everything outside the migration file keeps the old numbers, so these need a look after the import:

• IDs written in code. A form ID in your theme’s functions.php, in a code snippet plugin or in a third-party plugin’s settings is not touched.
• IDs inside notifications and confirmations. The text is copied as it is. A link or a merge tag inside it that names a form, an entry or a feed by its old ID keeps that old ID.
• Feed IDs in View field settings. A View field that stores a feed ID, such as a generated document link, keeps the old ID even though feeds are renumbered. Widgets are updated; fields are not.
• Pages that were already on the new site. Only the pages and posts inside the migration file are updated. A page that already existed on the new site and embeds a form by its old ID needs its shortcode or block updated by hand.
• Entry creators. The user ID recorded on each entry is carried across unchanged. On a site with different users, an entry shows as created by whichever user holds that ID there, or by nobody.

Repeating a migration #

The usual case is a site copied to staging, worked on, and moved back while the live site kept collecting entries. Since an import cannot fold the staging forms into the live ones, the move works like this:

1. Decide which site holds the version of each form you want to keep.
2. Export those forms from that site, with the data you want to carry.
3. On the other site, trash the old copies of the forms you are replacing, so the imported ones do not sit beside them.
4. Import the file.

The imported forms carry new IDs. Anything that pointed at the trashed forms by ID needs updating afterwards, from the list in the previous section. That covers a form embedded on an existing page, a snippet in your theme that names a form ID, and a View built on the old form that did not travel in the file.

Bringing only the new entries #

Entries submitted on the old site after you exported cannot be added through GravityMigrate to a form that already exists on the new site. Use Gravity Forms’ own entry export instead.

On the old site, export the form’s entries to CSV, filtered by the date range you need. Then import that CSV into the existing form with GravityImport, as Getting started with GravityImport describes. GravityImport creates the rows as new entries and does not update entries that are already there, so export only what the new site is missing.

The DROP TABLE lines in the migration file #

If you open the database dump inside a migration file, you will find DROP TABLE IF EXISTS lines in front of each table, with a warning above them. The import never runs those lines against your site’s tables. Every statement in the dump is rewritten to a set of temporary working tables with their own prefix before it runs, and any statement that names another table is refused. Your Gravity Forms tables receive the imported rows through inserts only, at the very end. Nothing on the destination is dropped, emptied or replaced by an import.

Related articles #

• Importing and exporting configured Views
• Where uploaded files go during a migration
• Getting started with GravityMigrate
• Best practices to follow when moving data using GravityMigrate