Migration
Migrating from Contact Form 7
Contact Form 7 ships on millions of WordPress sites. Migrating off it is mostly painless. The 5 things that aren't are worth knowing in advance.
Contact Form 7 has been the WordPress contact-form default for over a decade. It’s free. It works. It also ships zero spam protection, no submission storage, no integrations, and a quirky shortcode syntax.
Most sites can move off it in an afternoon. Here’s what migrates cleanly and what doesn’t.
The setup
Pick one form. Open Contact Form 7’s editor in one tab, Core Forms’ editor in another. Three things to migrate:
- The form HTML.
- The mail (notification email) settings.
- The success/error messages.
Plus, if you’ve added any third-party plugins to extend CF7 (Conditional Fields for CF7, CF7 Skins, etc.), those need to be considered separately.
What migrates clean
The form HTML. CF7’s syntax is roughly:
[text* your-name]
[email* your-email]
[textarea your-message]
[submit "Send"]Translate to standard HTML:
<p><label>Your name <input type="text" name="your-name" required /></label></p>
<p><label>Your email <input type="email" name="your-email" required /></label></p>
<p><label>Your message <textarea name="your-message"></textarea></label></p>
<p><button type="submit">Send</button></p>CF7’s [text*] becomes <input type="text" required />. CF7’s [email*] becomes <input type="email" required />. The asterisk in CF7 means required; in HTML it’s the required attribute.
For most forms, this translation takes 5 minutes. The HTML is what you’d write for any modern site.
Field names. CF7 names fields like your-name (with a dash). Core Forms preserves field names as-is. So if you’ve got a CRM mapping or an automation that depends on your-name, it keeps working.
Email notifications. CF7’s [your-name] and [your-email] syntax is the same in Core Forms. Drop the email body straight into the email action, it works without changes.
Success messages. Move them to the form’s Messages tab. Same content, different field.
What needs work
Spam protection. CF7 has no built-in spam filter. You probably layered Akismet (via the CF7 + Akismet plugin) and maybe a custom honeypot. Core Forms ships honeypot, rate limit, captcha, and Akismet as built-in features. The migration is “turn on the settings” instead of “install three plugins.” Easier, but it’s a different mental model.
Conditional fields. If you used Conditional Fields for Contact Form 7, the CF7 syntax [group group-name] doesn’t translate directly. Rewrite using Core Forms’ data-show-if attribute (covered in Conditional fields without a builder). Five minutes per form.
File uploads. CF7’s [file your-file filetypes:pdf|docx] becomes <input type="file" name="your-file" accept=".pdf,.docx" />. Same field, native HTML. Core Forms handles the rest.
Date pickers. CF7’s [date] shortcode renders a custom JS date picker. Core Forms uses native HTML5 <input type="date">. Modern browsers all support it; older browsers (IE11) don’t. For most modern audiences, native is better.
Custom validation rules. If you wrote custom CF7 validators using wpcf7_validate_* filters, they don’t carry over. Core Forms uses the cf_validate_form filter for the same purpose. Different name, same idea, ~5 lines of PHP to port.
What doesn’t migrate
CF7-specific add-ons. Contact Form 7 Multi-Step Forms, CF7 Repeatable Fields, CF7 Smart Grid, etc. These are CF7 ecosystem plugins. Most have Core Forms equivalents (multi-step is built in via [cf_step], repeatable fields are an HTML pattern). But you’re not “porting” them; you’re rebuilding using Core Forms’ native features.
CF7’s reCAPTCHA setup. CF7 ships reCAPTCHA at the global level (one set of keys for all forms). Core Forms supports per-form override of reCAPTCHA settings. If your CF7 setup had per-page reCAPTCHA hacks, the migration cleans them up.
Old submission emails. CF7 doesn’t store submissions. (That’s a feature gap, not a bug.) If you’ve been using a third-party plugin like Flamingo to store CF7 submissions, those records stay in Flamingo’s tables. Core Forms doesn’t import them. They’re still there if you need them.
The migration checklist
For each form on the site:
1. Copy the CF7 HTML to a notepad. Translate to standard HTML.
2. Copy the CF7 "Mail" settings to Core Forms' email action.
3. Copy the success/error messages to Core Forms' Messages tab.
4. Add captcha (Core Forms' settings → Spam protection).
5. Test with a real submission.
6. Replace the [contact-form-7] shortcode with [cf_form slug="..."] on the page.
7. Disable CF7's plugin only after you've tested every form on every page.Don’t disable CF7 until you’ve tested every form on every page. If a page has both a [contact-form-7] shortcode you missed and the new [cf_form] shortcode, the old form will silently 404 when you disable CF7.
What you gain
After migration:
- Submissions stored in the database (no more “did the email get sent?” anxiety).
- Spam protection layered correctly.
- Mailchimp, HubSpot, Slack, Notion, Webhooks — all native, no add-on plugins.
- Email logs (so deliverability problems are visible).
- Per-form override of nearly every setting.
CF7’s “free” cost was real. The maintenance cost (managing add-ons, debugging spam without storage, no email logs) was the hidden cost. Migration trades one for the other.
What you give up
CF7’s main advantage is “I already know it.” If you’ve trained your team on CF7’s syntax over years, the muscle memory has value.
For a single small site, the muscle memory might be worth keeping. For an agency running 20 client sites, the migration to a unified, integration-rich plugin pays for itself within a year.
The next step
Pick the simplest form on one client site. Migrate it as a test. Run it for a week, confirm submissions arrive, confirm the inbox looks right.
Then expand to the rest. The first migration is the slow one (you’re learning Core Forms’ patterns). The next ten are 10 minutes each.
Pricing here. The 14-day refund covers the “actually, CF7 was fine for us” outcome.