How to Migrate from ACF to JetEngine (or MetaBox) Without Losing Your Data
At some point, many WordPress developers face the same question: should I switch custom field frameworks?
Maybe ACF's licensing changes are pushing you toward MetaBox. Maybe JetEngine's custom content types better fit your project architecture. Maybe you're inheriting a client site built on one framework and your agency standardizes on another.
Whatever the reason, the migration itself is where things get painful. Because right now, there is no single tool that handles all migration directions between ACF, JetEngine, and MetaBox in one workflow.
The current migration landscape
Here's what your options look like today if you need to switch frameworks.
ACF to MetaBox: The best-supported path
MetaBox offers a free migration plugin called MB ACF Migration. It maps ACF field types to their MetaBox equivalents and handles the data transfer. It works with both ACF free and Pro, and it covers a surprisingly wide range of field types — including galleries, relationships, groups, repeaters, and flexible content.
The catch: you need to keep ACF active during migration, have the appropriate MetaBox extensions installed (like MB Term Meta if you're using taxonomy field locations), and verify everything manually after the migration completes. It's a solid tool, but it only handles one direction — ACF to MetaBox. If you're going the other way, or from either framework to JetEngine, it doesn't help.
ACF to JetEngine: Manual field remapping
Crocoblock's official documentation describes the process: go to your ACF field groups, note each field's name/ID, then recreate the fields in JetEngine using the same field names. Because both frameworks store meta values using the field name as the meta key, the data stays in wp_postmeta and becomes readable by JetEngine once the fields are set up.
For simple text and number fields, this works. For repeaters, relationships, and complex field types, you'll likely need custom code to transform the stored data format. ACF and JetEngine don't always serialize complex field data the same way.
This process is manual, error-prone, and scales poorly. Migrating a site with 30 ACF field groups means recreating every field by hand in JetEngine.
JetEngine to MetaBox or ACF: Barely documented
Going from JetEngine to MetaBox or ACF is even less supported. There's no dedicated migration plugin for this direction. The general approach is to export your data via CSV (using WP All Export with the JetEngine add-on), then re-import it into the target framework (using WP All Import with the appropriate add-on).
WP All Import's Import + Export Pro Package ($299/yr) bundles all framework add-ons, so the licensing is straightforward. But the CSV round-trip itself is the real problem. When you export JetEngine data to CSV, you flatten it — a JetEngine relation becomes a plain post ID, a MetaBox serialized group becomes a set of columns. Reconstructing the correct data format on the import side requires careful field configuration and often custom PHP functions.
The common thread: fragmentation
Every current migration path shares the same problem. You're stitching together multiple tools, each handling one piece of the workflow, with manual verification in between. There's no single place where you can say "take this ACF data and put it into JetEngine" and have it just work.
How UMIE approaches migration differently
UMIE includes a dedicated Migration View — a built-in interface specifically designed for moving data between field frameworks.
Because UMIE already includes drivers for ACF, JetEngine, MetaBox, WooCommerce, and native WordPress, it understands the schema and data format of each framework natively. It doesn't need add-ons for each direction. It doesn't need a CSV round-trip. It reads from one driver and writes to another through its Intermediate Representation (IR) layer.
The IR advantage
Here's the key architectural difference. When UMIE reads data from an ACF field group, it doesn't export it to a file. It converts it to an Intermediate Representation — a normalized data format that preserves the structure and relationships of your data regardless of which framework it came from.
That IR is then written to the target framework's driver. The ACF driver knows how to read ACF's dual-key system (field name + field key). The JetEngine driver knows how to write to CCT tables and handle relation entries. The MetaBox driver knows how to route data through rwmb_set_meta() for proper serialization.
The IR layer means UMIE can handle any direction: ACF to JetEngine, JetEngine to MetaBox, MetaBox to ACF, or any other combination. It's not a collection of one-way migration scripts — it's a universal translation layer.
Two-pass migration for relational data
If your data includes relational fields — ACF relationship fields, JetEngine relations, MetaBox post fields — UMIE uses a two-pass migration strategy. First pass: migrate all base records so the new post IDs exist in the target framework. Second pass: migrate relational fields using the newly created IDs.
This avoids the broken-reference problem that plagues CSV round-trips, where relationship values point to old IDs that no longer exist or have changed.
What the Migration View looks like
In practice, you open UMIE's Migration View, select your source (e.g., "ACF field group: Product Specifications") and your target (e.g., "JetEngine Meta Box: product_specs"). UMIE shows you the field mapping between frameworks, highlights any fields that don't have a direct equivalent, and lets you adjust the mapping before running.
The migration runs through UMIE's background processing queue (Action Scheduler), so it handles large datasets without timing out. Progress is logged at the row level, and any failures are flagged for manual review.
When to use this
The most common scenarios for cross-driver migration are switching frameworks for licensing, performance, or compatibility reasons (ACF Pro's pricing changes have driven many sites toward MetaBox or JetEngine), agency standardization where you're consolidating client sites onto a single field framework, and architecture refactoring where a site outgrows one framework's capabilities and needs the features of another — like moving from ACF to JetEngine for custom content type tables.
The alternative: don't migrate at all
It's worth noting that some sites run multiple field frameworks simultaneously. ACF and JetEngine can coexist. But this creates maintenance overhead, potential meta key conflicts, and a confusing developer experience. A clean migration to a single framework is almost always worth the upfront effort — if the migration tool makes it feasible.
Try the Migration View
UMIE's Migration View is available on Pro plans. If you're evaluating a framework switch, the free plan gives you enough to test the migration workflow with a subset of your data before committing.