{"id":277,"date":"2026-08-03T02:25:27","date_gmt":"2026-08-02T20:55:27","guid":{"rendered":"https:\/\/jnkplugins.com\/blog\/import-contact-form-7-entries-to-gravity-forms\/"},"modified":"2026-08-03T02:25:27","modified_gmt":"2026-08-02T20:55:27","slug":"import-contact-form-7-entries-to-gravity-forms","status":"publish","type":"post","link":"https:\/\/jnkplugins.com\/blog\/import-contact-form-7-entries-to-gravity-forms\/","title":{"rendered":"How to Import Contact Form 7 Entries into Gravity Forms"},"content":{"rendered":"

If you have landed here you are probably mid-migration: the site is moving from Contact Form 7 to Gravity Forms, the new forms are built, and you want the old submissions in the new Entries<\/strong> screen. First, an uncomfortable fact that trips up almost everyone searching for this: Contact Form 7 does not store entries at all by default.<\/strong> It builds an email, hands it to WordPress, and forgets the submission happened. There is no wp_cf7_entries<\/code> table waiting to be dumped.<\/p>\n

So the real question is not “how do I import CF7 entries into Gravity Forms” \u2014 it is “where, if anywhere, did my submissions get stored?” Answer that and the rest is mechanical. There is a longer explanation in does Contact Form 7 store data?<\/a>, but the short version above decides everything that follows.<\/p>\n

Step 1: diagnose which situation you are actually in<\/h2>\n

There are three realistic scenarios. Check them in this order, because the first one you match is the one you work with.<\/p>\n

Scenario A \u2014 you had Flamingo installed<\/h3>\n

Flamingo is the companion plugin from CF7’s own author. If it was active, your submissions are sitting in WordPress as a custom post type called flamingo_inbound<\/code>, with each field stored in post meta prefixed _field_<\/code>. Look in the admin sidebar for Flamingo → Inbound Messages<\/strong>. If you see rows there, you have data and a clean path forward.<\/p>\n

One caveat: Flamingo only captured submissions made while it was active<\/em>. If you installed it in March, nothing from February exists. Check the oldest message date before promising anyone a complete history.<\/p>\n

Scenario B \u2014 you used a CF7 database add-on<\/h3>\n

Plugins like Contact Form CFDB7 write to their own table \u2014 typically wp_db7_forms<\/code> \u2014 storing the whole submission as one serialized PHP blob. Recoverable, but the export step means unserializing before you get anything CSV-shaped.<\/p>\n

Scenario C \u2014 you have nothing but email<\/h3>\n

No Flamingo, no add-on. In that case there is no database to export from and no honest way to reconstruct a complete entry set. We would rather say that plainly than sell you a workflow that quietly loses half your data.<\/p>\n

What you can<\/em> salvage: export the mailbox folder that received the notifications (most clients export .mbox<\/code> or .eml<\/code>; Gmail does it via Google Takeout). CF7 notifications follow a fixed template, so if it never changed you can parse them with reasonable accuracy. It falls apart on multi-line message fields, forwarded threads, and notifications that bounced or were spam-filtered. Treat the result as an archive for reference, not a faithful entry table.<\/p>\n

Step 2: get the old entries out to CSV<\/h2>\n

From Flamingo.<\/strong> Select the messages on the Inbound Messages screen and choose Export<\/strong>: you get one row per submission. It is basic \u2014 it exports what it stored, in the column order it likes \u2014 but it is trustworthy. For finer control over columns or date formatting, our walkthrough of exporting Contact Form 7 entries to CSV<\/a> covers the options.<\/p>\n

From a database add-on.<\/strong> CFDB7 ships its own per-form export button, which is the easiest route. If it chokes on a large table, query the table directly \u2014 but remember the serialized column. A small WP-CLI script that runs maybe_unserialize()<\/code> over each row and writes fputcsv()<\/code> output beats a generic phpMyAdmin export, which will hand you raw a:7:{s:4:\"name\"...}<\/code> strings.<\/p>\n

Whatever the source, open the CSV in a text editor before you go further. You are checking for three things: a consistent column count on every row, dates in one format rather than three, and no stray line breaks inside message fields that have broken the row structure.<\/p><\/blockquote>\n

Step 3: import into Gravity Forms<\/h2>\n

Here is the second uncomfortable fact: Gravity Forms has no native CSV entry importer.<\/strong> It exports entries beautifully and imports nothing. So you pick one of three routes.<\/p>\n\n\n\n\n\n
Route<\/th>\nGood for<\/th>\nPros<\/th>\nCons<\/th>\n<\/tr>\n
Gravity Forms CLI add-on (wp gf entry create<\/code>)<\/td>\nAnyone comfortable on the command line<\/td>\nOfficial, free with your licence, scriptable, no extra plugin on the front end, easy to re-run after a bad batch<\/td>\nRequires WP-CLI and SSH; you write the loop that reads the CSV yourself<\/td>\n<\/tr>\n
Third-party entry-import add-on<\/td>\nNon-technical site owners, one-off migrations<\/td>\nPoint-and-click column mapping, previews before committing, handles the entry meta for you<\/td>\nUsually paid; mapping UIs vary in quality; another plugin to maintain or remove afterwards<\/td>\n<\/tr>\n
Custom script using GFAPI::add_entry()<\/code><\/td>\nMessy or unusual source data<\/td>\nTotal control over parsing, transformation and field IDs; can set the original date directly<\/td>\nYou own the bugs; needs a real staging environment and care with large batches<\/td>\n<\/tr>\n<\/table>\n

All three ultimately do the same thing: build an entry array keyed by Gravity Forms field IDs<\/strong> and hand it to the API. Which brings us to the part that actually costs people time.<\/p>\n

Field mapping: where migrations go wrong<\/h2>\n

Gravity Forms does not identify fields by name. It identifies them by numeric ID, and complex fields use decimal sub-IDs. Open your form, note the ID of each field (the editor shows it, or check the URL when editing a field), and write the mapping down before you touch any code.<\/p>\n