Renaming ACF Fields: SQL vs WP-CLI vs Better Search Replace vs Plugin
All four approaches change the same thing: the meta_key in wp_postmeta. They differ in scope and in what they can prove afterwards. Two UPDATE queries are precise and free, but unverified and easy to mis-scope. WP-CLI is the same queries with better ergonomics and a count you can run first. Better Search Replace is the wrong tool — it is built to rewrite serialized values, not rename keys, and it will match substrings you did not intend. A dedicated plugin costs money and buys you a preview, verification, and a rollback.
What every approach is actually doing
ACF stores a value row under the field name and a reference row under the same name prefixed with an underscore. A rename means both rows move to the new name, on every post, revision, and autosave that holds the field. Everything below is a different way of issuing that one change.
The four approaches side by side
Every row above except the last one shares a weakness: you find out what the change did after it has already run. See what the impact review shows →
Two UPDATE queries
Precise if you scope them exactly, and free. The risks are all in the scoping: a LIKE instead of an =, a wrong table prefix, another top-level field using the same name, or a multisite install where every subsite has its own postmeta table. There is no built-in dry run or retained recovery record; you must write the preflight checks and prepare the recovery path yourself.
UPDATE wp_postmeta SET meta_key = 'contact_phone'
WHERE meta_key = 'employee_phone';
UPDATE wp_postmeta SET meta_key = '_contact_phone'
WHERE meta_key = '_employee_phone';Forgetting the second statement is the most common mistake. The values move, but their underscore-prefixed ACF references remain under the old name, leaving incomplete metadata pairs.
WP-CLI
The better version of the same thing. Resolve the prefix with wp db prefix, count before and after, and target subsites with --url. Still no preview of which content types and how many records are affected, and still nothing that reads the values back.
Better Search Replace
It is an excellent plugin doing a different job. It walks tables replacing a string inside values, unserializing safely as it goes. Point it at a field name and it will also rewrite that string wherever it appears inside serialized options, block markup, saved queries, and other fields’ content. You get no key-level precision and no record-level report — just a replacement count.
If you have already run Better Search Replace for a field rename, check wp_options and post_content for stray replacements before doing anything else. Those are the ones nobody notices for weeks.
What each one leaves behind
The differences show up after the change, not during it. Manual SQL and WP-CLI leave no migration record or retained source rows; a carefully reversed UPDATE may work before later writes occur, otherwise recovery depends on the backup. Better Search Replace can affect every selected value containing the string. A verified migration leaves the original rows in place, a recorded record count, and a reverse operation.
Two things survive every approach and none of them handle: a persistent object cache still serving pre-rename values, and every reference to the old name in your source, imports, and integrations.
A dedicated plugin
It costs $49 and it is not magic — it issues comparable writes. What it adds is everything around them: matching on the stable field key rather than the name, an impact review showing affected content types and record counts, conflict detection where both keys already hold a value, batched copy with read-back verification before the definition switches, retained originals, and verified rollback.
- Full database backup
- Locate the correct metadata rows
- Write and run both UPDATE queries
- Verify the counts by hand
- Find and fix whatever you missed
- Impact preview with record counts
- Conflict detection before any write
- Batched copy, every value read back
- Originals retained until you delete them
- Verified rollback
Which to pick
Your own site with a fresh backup and one simple field: SQL or WP-CLI is entirely reasonable. A client site, a populated field, or a rename you would struggle to explain if it went wrong: use something that shows you the blast radius first.
Common questions
Can I use Better Search Replace to rename an ACF field?+
You can run it, but you should not. It replaces a string inside values across whole tables rather than renaming a specific meta_key, so it will also rewrite that string in serialized options, block markup, and unrelated field content.
Is WP-CLI safer than raw SQL?+
Marginally. It resolves the table prefix for you and makes multisite addressable, which removes the two most common scoping mistakes. It still cannot preview the affected records or read values back afterwards.
Why would I pay for something two queries can do?+
For one field on your own site with a backup, you probably would not. The $49 buys the preview, the conflict detection, and the rollback — which matter when the field is populated and the site belongs to a client.
What does Field Renamer verify that a query does not?+
It proves ownership through the field-key reference, blocks destination and definition conflicts, copies in batches, reads every copied value back, and records the operation for rollback.
What is the actual risk with manual SQL?+
Mis-scoping or changing data during the cutover. A LIKE where you meant =, a wrong table prefix, another field using the same name, or a concurrent write can all produce a result the database accepts but ACF cannot safely use.