Migrate Form Entries Between WP Form Plugins

Switching form plugins is easy. Moving the years of submissions sitting behind the old one is not. Most sites hit this the same way: a plugin gets abandoned, a license gets too expensive, or three different builders have accumulated over a decade and someone finally decides to consolidate. Then comes the uncomfortable question — what happens to the 4,000 entries already in the database?

Here’s the honest starting point: almost no WordPress form plugin ships an official cross-plugin entry importer. Several will import another plugin’s form definitions (Fluent Forms, WPForms and Formidable all do some version of this), but that migrates the fields and labels, not the submissions. For entries, CSV is the lingua franca. This guide walks through doing that migration properly — what you risk losing, how to map fields between two plugins that name everything differently, and how to verify you didn’t quietly drop half the data.

What you actually risk losing

People assume a migration either works or doesn’t. In practice it usually “works” and silently loses a subset of things. Know the list before you start:

Entries themselves — the obvious one, and usually the part that survives.
Uploaded files. This is the big one. A CSV export of a file-upload field gives you a URL, not the file. If you later delete the old plugin — or it cleans up its uploads directory on uninstall — those URLs 404 and the attachments are gone.
Timestamps. Many importers stamp every imported row with today’s date. Suddenly four years of enquiries all look like they arrived on Tuesday, and any date-based reporting is worthless.
Entry status and notes. Read/unread, starred, spam, trashed, payment status, and admin notes typically live in plugin-specific meta tables that never make it into a CSV export at all.
Field mapping. Gravity Forms stores entries against numeric field IDs (1, 2.3), Contact Form 7 against tag names (your-email), WPForms against its own field IDs. The same human question has three different machine names, and nothing reconciles them for you.
Multi-value fields. Checkboxes, multi-selects and repeaters flatten into one cell — sometimes comma-joined, sometimes one column per choice. The destination almost never expects the same shape.

Plan the migration before you touch anything

Twenty minutes of planning here saves a bad afternoon later.

1. Inventory what holds entries

Walk the site and list every plugin that currently stores submissions, how many entries each holds, and the date range. Older sites regularly turn up a forgotten builder still collecting into a table nobody reads. If you’re not sure what’s storing what, our guide to storing and exporting WordPress form entries covers which plugins save to the database and which don’t (Contact Form 7, famously, doesn’t).

2. Decide what must survive vs what is archive-only

Not all of it needs to be live in the new plugin. Be blunt about it: last 12 months of leads that sales still work → must migrate, fully mapped. Everything older → archive-only, a CSV in cold storage is fine. This single decision usually cuts the hard mapping work by 80%, because archive rows don’t need perfect field alignment — they just need to be readable.

3. Never migrate on production without a backup

Take a full database backup and a copy of wp-content/uploads before the first import. Better still, do the whole rehearsal on a staging clone, and only run it on production once you know the row counts come out right. Imports are hard to un-run — a botched one leaves duplicates you then have to identify and delete by hand.

A migration you can’t roll back isn’t a migration, it’s a bet. If your host offers one-click staging, this is the exact scenario it exists for.

Step 1 — Export from the source plugin

Every storing form plugin has some export, and the flow differs enough per plugin that it’s worth following a dedicated guide rather than guessing. For Gravity Forms specifically, our walkthrough of exporting Gravity Forms entries covers the built-in screen, its per-form limitation, and the API route. In general terms:

Export one form at a time. Most exporters work per-form anyway, and per-form files are far easier to map than one giant merged CSV.
Include the metadata columns — entry ID, submission date, user IP, source form, payment status. Tempting to skip; painful to be without later.
Check whether spam and trashed entries are included. Several exporters silently omit them, which is fine — as long as you know, so the counts don’t confuse you at verification time.
Export UTF-8. Non-English names and accented characters are where CSV encoding bugs surface.
Download the actual uploaded files separately, via FTP or a file-manager, before the old plugin ever gets deleted.

If the source plugin has no export at all (some abandoned ones don’t), you’re down to reading the rows out of the database directly with phpMyAdmin or WP-CLI and writing your own CSV. Doable, but budget real time for it.

Step 2 — Normalise the CSV (this is the hard part)

Exporting takes five minutes. Normalising is where migrations are won or lost. Open the export in a spreadsheet and do four passes.

Map the fields

Build an explicit mapping table before editing anything. A real one looks like this:

Source column (old plugin)	Meaning	Destination column (new plugin)	Transform needed
`1.3` / `1.6`	First name / Last name	`name`	Concatenate with a space
`your-email`	Email address	`email`	Trim, lowercase
`date_created`	Submission time	`submitted_at`	Reformat to `Y-m-d H:i:s`, convert timezone
`field_7`	Interests (checkboxes)	`interests`	Join values with `;`
`file_upload_2`	Attachment	`attachment_url`	Re-host file, rewrite URL
`entry_id`	Old primary key	`legacy_id` / note field	Keep for traceability

That last row matters more than it looks: carrying the old entry ID into a spare column or the notes field means that six months from now you can still trace an imported record back to the original system.

Fix the dates

Date formats are the most common breakage. Exports come out as 2024-03-11 14:02:00, 11/03/2024, 03/11/2024 or a Unix timestamp depending on the plugin and your locale — and 11/03 is ambiguous between two continents. Convert everything to ISO YYYY-MM-DD HH:MM:SS in one pass, and check whether the source stored UTC or site-local time so you don’t shift every record by hours. Watch out for spreadsheets “helpfully” reformatting a date column the moment you open the file; format the column as text first.

Un-flatten multi-value fields

Decide on one separator for checkbox and multi-select values (a semicolon is safer than a comma inside a CSV) and apply it consistently. If the source exported one column per choice — Interest_Design, Interest_SEO, each holding Yes/blank — collapse those into a single delimited column before import.

Deal with uploads properly

Copy the actual files to the new location (usually somewhere under wp-content/uploads) first, then rewrite the URL column to point at the new paths. Importing the old URLs and planning to fix them later is how attachments get lost — the moment the source plugin is removed, there’s nothing to fix them against.

Step 3 — Import and verify

Import into the destination plugin’s CSV importer if it has one (EntryVault, Formidable and several others do; Gravity Forms needs an add-on such as WP All Import). Then verify — properly, not by vibes:

Do a test import of 10 rows first. Check them, then delete them, then run the full file. Never make the full run your first attempt.
Compare row counts. Source export rows vs imported entries, per form. If they differ, find out exactly why (skipped header? blank rows? spam excluded at export?) before moving on.
Spot-check the extremes. Open the oldest entry, the newest entry, and three random ones in the middle. Confirm the date, every mapped field, and any attachment link actually resolves.
Check the awkward rows deliberately — an entry with accented characters, one with a comma or quote inside a text field, one with multiple checkbox values, one with an empty optional field.
Test a live submission on the new plugin so you know new data lands correctly alongside the migrated data.

Step 4 — Keep the old data around

Don’t delete the source plugin the same day. The failure mode is discovering three weeks later that a field didn’t map, when the original is already gone.

Take one final full CSV export from the old plugin and store it outside the site (cloud storage, not wp-content).
Deactivate the old plugin rather than deleting it, so it stops collecting new entries but keeps its tables. Note that some plugins drop their tables on uninstall, not deactivation — which is exactly why deleting is the risky step.
Keep a database dump of the old plugin’s tables specifically, labelled and dated.
Give it a sensible window — one full business cycle, usually a month or a quarter — before you remove anything. Then delete deliberately, not accidentally.

The alternative: don’t migrate, adopt a capture layer

Everything above is the cost of having submissions locked inside whichever builder happened to render the form. There’s a structural fix: put a storage layer beside your form plugins that records every submission independently of which builder produced it. Then switching builders is a config change, not a data project — the historical record already lives somewhere neutral, and the new plugin just becomes another source feeding the same board.

Full disclosure, this is what we build: our free EntryVault plugin captures entries from 11 form builders into one searchable board, with CSV import and export both in the free tier — so the next time you switch, there’s no migration to run. It’s not the only way to do this; the point is the pattern, and our roundup of the best WordPress form entry management plugins covers the alternatives fairly.

Either way, the rule holds: whatever plugin you land on, make sure you can get a complete CSV out of it on demand. The plugin you can export from is the plugin you’re never trapped by.

Frequently asked questions

Can I move form entries from one WordPress form plugin to another?

Yes, but almost always via CSV rather than a one-click tool — most form plugins have no official cross-plugin entry importer. Some can import another plugin’s form definitions (fields and labels), which is a different job from moving submissions. The reliable route is to export entries from the old plugin as CSV, normalise the columns, dates and multi-value fields, then import into the new one.

Will I lose uploaded files when migrating form entries?

You can, easily. A CSV export stores file-upload fields as URLs, not as the files themselves, so if the old plugin is deleted and its uploads are cleaned up, those links break. Copy the actual files to their new location first, then rewrite the URL column to point at the new paths before importing.

Should I delete the old form plugin after migrating?

Not immediately. Deactivate it so it stops collecting new entries, but keep its tables and take one final CSV export stored outside the site. Some plugins drop their data on uninstall, so wait a full business cycle and confirm every field mapped correctly before deleting anything.

The bottom line

Migrating form entries is a data job, not a plugin job: inventory what you have, back it up, export to CSV, and spend your time on the mapping — field names, date formats, multi-value columns and uploaded files — because that’s where the losses hide. Verify by counting rows and opening the oldest and newest entries, keep the old plugin dormant until you’re certain, and then consider storing future submissions somewhere builder-independent so you only ever have to do this once.