What Happens to Your ACF Data When You Migrate to Statamic?

If you’ve spent any time building serious WordPress sites, you’ve probably built half your content model in Advanced Custom Fields. Text fields, image fields, repeaters, flexible content layouts — ACF is what turns WordPress from a blogging platform into something that can actually hold structured content. It’s good software, and the teams that rely on it have usually invested real time in their field groups, their field keys, and the templates that consume them.

So when the topic of migrating to Statamic comes up, ACF is often the first thing that surfaces. "But all our data is in ACF." It’s not an unreasonable concern. Let’s go through what actually happens.

How ACF and Statamic model data differently

ACF stores custom field data in WordPress’s wp_postmeta table, keyed to post IDs. Each field is a row in that table, with the field key and value stored separately. Complex fields like repeaters and flexible content get serialized or stored as multiple related rows. It works, and it’s served millions of sites well, but the underlying storage is a layer of abstraction on top of a database schema that wasn’t designed for structured content from the start.

Statamic’s flat-file approach stores content differently. Each entry is a Markdown or YAML file, with front matter that holds your structured fields. A post with a title, a set of repeating items, and an image reference looks like a readable file you could open in a text editor and understand immediately. In Eloquent mode (Statamic’s database driver), the same data lives in a proper relational schema rather than the postmeta pattern.

The content model you define in Statamic — your blueprints and their fieldtypes — maps cleanly to the things ACF gives you. The concepts are the same. The underlying storage and the developer experience are meaningfully better.

Field type mapping

Most ACF fields have direct or near-direct equivalents in Statamic. Here’s how the common ones translate:

Text, Textarea, Number, Email, URL — Statamic has all of these as first-class fieldtypes. The mapping is one-to-one and the migration is straightforward.

WYSIWYG — Statamic has Bard, which is a structured rich text editor built on ProseMirror. If you’re used to ACF’s TinyMCE-based WYSIWYG, Bard is a significant upgrade: it supports inline images, embeds, custom component sets, and outputs clean, portable content. Migrating your HTML content into Bard is usually a matter of converting it to Bard’s JSON format, which tools can handle programmatically.

Image — Statamic’s Assets fieldtype handles single images. Rather than storing a WordPress attachment ID, it stores a reference to an asset in a configured container (local filesystem, S3, etc.). The migration involves moving your media files to the asset container and updating the references.

Gallery — Same as Image, but Statamic’s Assets field in multi-select mode. Works the same way, migrates the same way.

Select, Radio, Checkbox, True/False — Direct equivalents exist in Statamic. The migration is a simple value mapping.

Relationship and Post Object — Statamic’s Entries fieldtype handles relationships between entries. Instead of storing WordPress post IDs, it stores Statamic entry IDs. The relationship model is the same; the migration requires mapping old IDs to new ones, which is a standard step in any content migration script.

Taxonomy — Statamic has a Terms fieldtype that works with Statamic taxonomies. WordPress categories and tags migrate to Statamic taxonomies; the term references in your entries update accordingly.

Date and Date/Time — Direct equivalents. Statamic’s Date fieldtype supports both date-only and datetime values.

User — Statamic has a Users fieldtype. WordPress user IDs map to Statamic user IDs during migration.

Link — Statamic has a Link fieldtype that handles internal and external URLs. ACF’s Link field (which returns an array with URL, title, and target) maps cleanly.

Repeaters and Flexible Content

These are the fields that tend to make developers most nervous, and understandably — they often hold the most complex data.

ACF Repeater → Statamic Grid or Replicator

Statamic’s Grid fieldtype is the direct equivalent of an ACF Repeater. You define a set of subfields, and each row is a repeated instance of that set. The structure is identical. If your ACF repeater has a text field, an image field, and a URL field, your Statamic Grid will have the same. Migration is a row-by-row conversion of the repeater data into Grid rows.

ACF Flexible Content → Statamic Replicator

This is the one that gets the most attention, because ACF Flexible Content is powerful and the data can get complex. Statamic’s Replicator is the equivalent: a field that holds multiple sets, where each set has its own collection of subfields. You define your sets in Statamic (equivalent to your ACF layouts), and migration converts each flexible content row to the appropriate Replicator set.

The key difference is that Statamic’s Replicator stores data in a clean, typed structure rather than WordPress’s serialized meta format. Once your flexible content data is in Statamic, it’s easier to query, reason about, and work with in templates.

ACF Groups → Blueprint fieldsets or Replicator sets

ACF Groups (a collection of fields that don’t repeat) typically map to fields defined directly in a Statamic blueprint. There’s no separate "group" wrapper needed — the blueprint itself is the organizational layer.

ACF Clone → Statamic imported fieldsets

ACF’s Clone field lets you reuse a field group inside another field group — a way to share a consistent set of fields across multiple post types without duplicating the definition. Statamic has a direct equivalent: imported fieldsets. You define a fieldset once as a standalone YAML file, then import it into any blueprint or Replicator set that needs it. The concept is the same — a reusable, centrally-defined block of fields — and the migration path is to extract the cloned group into a Statamic fieldset and import it wherever it’s referenced.

ACF Options Pages → Statamic Globals

If you’ve used ACF Options Pages to store site-wide settings — things like a phone number, a default image, global call-to-action text — those map to Statamic Globals. Statamic’s Global Sets are YAML files (or database rows in Eloquent mode) that hold site-level variables accessible from any template. The migration is a straightforward copy of the options data into a Global Set with matching field definitions.

What the migration actually looks like

A migration typically involves a script — usually a Laravel Artisan command — that reads from the WordPress database and writes Statamic content files. The broad steps:

1. Export from WordPress — Connect to the WordPress database and query posts, postmeta, terms, and users.
2. Map field values — For each ACF field, convert the stored value to its Statamic equivalent. Simple fields are direct copies; complex fields like repeaters require deserializing WordPress’s format and restructuring the data.
3. Write Statamic entries — Create content files (or database rows) with front matter that matches your Statamic blueprints.
4. Handle media — Move WordPress uploads to your Statamic asset container and update image references throughout the content.
5. Verify — Spot-check entries in the Statamic control panel, run your test suite, and confirm that templates are rendering the data correctly.

The complexity of this process scales with the complexity of your content model. A site with straightforward ACF fields — mostly text, images, and a few repeaters — is a manageable migration. A site with deeply nested flexible content, extensive relationships, and heavy use of ACF’s more specialized fieldtypes (like Google Map or oEmbed) requires more careful handling of each edge case.

This is why migrations like these are rarely pure DIY projects. The script work is knowable — none of it is mysterious — but it takes experience to anticipate edge cases, handle data inconsistencies from years of content editing, and get it right without data loss.

What gets better

Most things, actually — though not because Statamic’s field types are dramatically more capable than ACF’s. They’re comparable. The difference is what happens to the data structure once it’s in Statamic.

Your content model is now defined in blueprint YAML files that live in your repository. The field definitions are code, version-controlled, reviewable in a pull request. ACF field groups are database records, which means they can get out of sync between environments, can’t be easily diffed, and require explicit import/export tooling to move between staging and production.

Your content files are readable. An ACF-powered WordPress post has its custom field data scattered across dozens of wp_postmeta rows. A Statamic entry file has everything in one place, in a format a human can read without running a database query.

Your relationships are explicit. ACF stores relationship field values as arrays of WordPress post IDs. What post does ID 4872 correspond to? You’d need to query the database to find out. Statamic stores relationships as entry slugs or IDs in a way that makes the relationship visible and understandable without extra lookups.

What to watch out for

A few things worth knowing before you start:

Custom fieldtype plugins — If you’ve been using ACF add-ons that provide custom fieldtypes (color pickers, icon selectors, etc.), those don’t have automatic equivalents in Statamic. You’ll need to either find a Statamic addon that covers the same need or rebuild the custom field as a combination of standard Statamic fieldtypes.

Very large repeaters — If you have entries with repeaters that hold hundreds of rows, the flat-file format can produce large YAML files. For sites with this kind of data volume, Statamic’s Eloquent mode (database storage) is the right call.

Conditional logic — ACF supports conditional field display based on other field values. Statamic has conditional field visibility as well, but the implementations are different. Your conditions will need to be redefined in Statamic’s blueprint format rather than being automatically migrated.

None of these are blockers. They’re just things to scope carefully when planning the migration rather than discovering mid-project.

The data is fine

The short version: your ACF data is not a reason to stay on WordPress. The field types map. The structures translate. The migration is a known process with known steps. What you get on the other side is the same content model, in a platform that treats your content as structured data rather than serialized strings in a meta table.

If the ACF question has been the hesitation, it’s a solvable problem. The more useful question is whether your team is ready to work in Laravel — because that’s the environment your Statamic site will live in, and that’s where the real transition happens.