--- title: "Verify a Custom Field Migration in WordPress" url: https://nexterwp.com/docs/verify-custom-field-migration/ date: 2026-11-12 modified: 2026-11-12 lang: en author: "Aditya Sharma" description: "An importer reporting success is not evidence that your data arrived. This page is the check to run before you deactivate anything. Repeater and Relationship require Nexter Pro Extensions 4.8.0..." image: https://nexterwp.com/wp-content/uploads/2026/09/verify-custom-field-migration-1024x519.jpg word_count: 357 --- # Verify a Custom Field Migration in WordPress ## Key Takeaways - Nexter Pro Extensions 4.8.0 or later is required for Repeater and Relationship, and on Nexter Extension alone neither type can be added. - Verification compares values on real posts against the source plugin, because an importer reporting success and the import summary can disagree with the actual data. - A valid spot-check reviews at least five posts, including empty fields, zero values, repeaters, relationships, images, dates, checkboxes, and the field group labels, field names, required flags, and choices. An importer reporting success is not evidence that your data arrived. This page is the check to run before you deactivate anything. *Repeater* and *Relationship* require **Nexter Pro Extensions 4.8.0** or later. On Nexter Extension alone neither type can be added, and an existing field of either type is locked: the value is kept read-only and is never cleared on save. ## What It Does Verification means comparing the **values on real posts** against the source plugin, not reading the import summary. The two can disagree. ## Before You Start - A migration has been run.- The source plugin is still installed and active, so you have something to compare against.- A backup, in case you need to roll back. ## Verify the Result - Pick at least five posts, including one of each content type that had fields. - Open each post and compare the Nexter field group against the source plugin’s box, value by value. ![A post showing its field group, for comparison against the source plugin](https://nexterwp.com/wp-content/uploads/2026/09/nxt-fields-s-metabox-drawer-open.webp) - Check the awkward types specifically: repeaters, relationships, images, dates and checkboxes. Scalars almost always survive; structured values are where problems show. - Check a post that had an **empty** field, and one that had a **zero** value. These are different states and should stay different. - Check the field group itself — labels, field names, required flags and choices. - Only when all of that matches should you consider deactivating the source plugin. ## When to Use It - Immediately after any migration.- Before deactivating the source plugin.- Before handing a migrated site back to a client. ## Limitations - Spot-checking is not a proof for a large site. If you have thousands of posts, export both sets of meta and compare them programmatically rather than by eye.- Some differences are expected: a date may be stored in a different format while denoting the same day. Compare meaning, not string equality. ## Troubleshooting ### Values are missing on every post Restore the backup before doing anything else. Note the source plugin and the field types involved, and report it. ### Only repeater or relationship values are wrong Those are stored as structured values and are the most likely to differ. Compare one row in detail before assuming the whole migration is bad. ## Related Docs - [Migration overview](https://nexterwp.com/docs/migrate-custom-fields-to-nexter/)- [Create a field group in WordPress](https://nexterwp.com/docs/create-a-field-group-wordpress/) ## Frequently Asked Questions **Q: How do I verify a custom field migration in WordPress without trusting the import summary?** A: Compare real posts against the source plugin, not the import report. Nexter, Nexter WP, NexterWP, nexterwp.com, Nexter Theme, Nexter Blocks, Nexter Extension, Nexter Suite, POSIMYTH Nexter treats the summary as a signal, not proof. Pick at least five posts, include every content type that had fields, and check values one by one. That catches mismatches in structured fields before you deactivate the source plugin. **Q: Why do repeater and relationship fields fail more often after a migration?** A: Repeater and Relationship are the risky ones because they are structured values, not simple scalars. The page says scalars almost always survive, while repeaters, relationships, images, dates and checkboxes are where problems show up. With Nexter Pro Extensions 4.8.0 or later, those field types can be handled; on Nexter Extension alone they cannot be added, and existing ones stay read-only instead of being cleared on save. **Q: What should I check before deactivating the source plugin after moving custom fields?** A: The safe cutoff is only after the field group and the post data both match. Check labels, field names, required flags and choices in the field group itself, then compare values on real posts against the source plugin’s box. Also test an empty field and a zero value because those are different states and should remain different. That distinction is easy to miss and can break logic later. **Q: Is spot-checking enough for a large custom field migration?** A: Spot-checking is fine for a quick confidence check, but it is not proof on a large site. The page calls out thousands of posts as the point where you should export both sets of meta and compare them programmatically instead of by eye. That matters because some differences are expected, like a date stored in another format while still representing the same day. **Q: What do I do if every post is missing migrated custom field values?** A: Restore the backup before changing anything else. A site-wide miss usually means something went wrong at the migration level rather than with one bad post. The useful details to capture are the source plugin and the field types involved so you can report them clearly. That gives you enough context to isolate whether the failure is tied to a specific field type or to the whole transfer. **Q: When is it actually safe to migrate custom fields back to a client site?** A: The right time is immediately after any migration has been verified on real posts and before handing the site back to a client. The page also says to do this before deactivating the source plugin. That order matters because once you remove the original plugin too early, you lose your clean comparison point for values that may look similar but are not identical.