Migrations

Rename a database-managed ACF field

Updated 3 August 2026 · 6 min read · applies to v0.1.0+

This walkthrough covers renaming a top-level ACF field whose field group is stored in the database. Local JSON groups use a different guided workflow.

Before you start

Take a database backup. Field Renamer preserves original metadata and offers verified rollback, but a restore point is still the responsible baseline for a structural production change.

Selecting the field

Fields are matched by their stable ACF field key, not their name. This prevents the rename from touching an unrelated field that happens to share a metadata name.

get_field( 'employee_phone', $post_id );

Reviewing the impact

The review shows the field, definition source, storage location, content types, record count, revisions, conflicts, warnings, and rollback availability. Nothing is written until you approve it.

A destination collision or ambiguous metadata is a blocking conflict. Field Renamer does not overwrite or skip it silently; resolve the conflict before starting.

Running the migration

A write lock is placed on the field, values are copied in bounded batches of up to 200 records, and each batch is read back and compared. Only after full verification does the field definition switch to the new name.

After the cutover

Update template code and saved queries that reference the old name. Original metadata stays in place until you deliberately clean it up.