What about my WordPress custom fields and ACF data?

ACF and custom field data migrates well. The structural concepts map between the two platforms closely enough that this is one of the more straightforward parts of a WordPress-to-Statamic migration, though it requires some deliberate planning.

In WordPress with ACF, you define field groups attached to post types or page templates, and those fields store data in the wp_postmeta table. In Statamic, the equivalent is blueprints and fieldsets — you define fields attached to collections or entries, and data is stored as YAML front matter in your content files (or in the database, in database mode).

Most ACF field types have direct Statamic equivalents: text, textarea, number, true/false, select, radio, checkbox, image, file, link, relationship, repeater, flexible content. The field names don’t need to match — you define new Statamic field handles during the migration — but the data maps over.

Repeater fields and flexible content blocks deserve special mention because they tend to hold the most complex data. Statamic has Replicator (analogous to flexible content) and Grid (similar to repeaters). The data structure differs, so these require custom migration scripts to reshape the data from WordPress’s serialized format into Statamic’s expected structure. This is doable, but it’s also where content structure decisions matter most. The migration is a good time to ask whether your existing flexible content architecture makes sense to carry forward as-is, or whether it could be improved.

Gallery fields and image relationships migrate well. Statamic’s Assets system handles media, and images can be linked by path or ID in the migrated content. We typically migrate the WordPress media library as part of the content migration.

ACF Pro features like options pages can be replicated using Statamic Globals, which serve a similar purpose — site-wide settings and data that isn’t attached to a specific entry.

One thing to check before migration: ACF data in WordPress is only as clean as the content editing that produced it. If fields were optional and editors sometimes filled them in inconsistently, or if field groups changed over the years and old content has orphaned metadata, the migration script needs to handle those cases gracefully. The audit phase is where we identify these edge cases.

If you’re relying heavily on ACF for your content architecture, our migration guide goes deeper on the blueprint mapping process.