# What happens to custom fields and ACF data after migration? > When you migrate off WordPress, your custom fields, including Advanced Custom Fields data, need a deliberate decision, because that data lives in the database and is rendered into your templates, so how you migrate it depends on whether you need the finished output or the structured data itself. If you just need pages to look the same, a capture of the live site gets the rendered result, since the custom fields are already baked into what visitors see. If you need the structured data as data, for example to rebuild a directory, spec table, or templated layout on the new site, you export the fields from the source, through the WordPress REST API or an export, because the raw values are not separable from a front-end capture. So the question is output versus data, and you choose based on how the new site will use it. WPBuildAI captures the rendered output for a faithful visual rebuild and, where you need the structured values, exports the custom field data so it can be re-templated on the new platform. Source: https://wpbuildai.com/what-happens-to-custom-fields-acf-after-migration/ By lawrence-arya ยท 2026-06-16 --- When you migrate off WordPress, your custom fields, including Advanced Custom Fields data, need a deliberate decision, because that data lives in the database and is rendered into your templates, so how you migrate it depends on whether you need the finished output or the structured data itself. If you just need pages to look the same, a capture of the live site gets the rendered result, since the custom fields are already baked into what visitors see. If you need the structured data as data, for example to rebuild a directory, spec table, or templated layout on the new site, you export the fields from the source, through the WordPress REST API or an export, because the raw values are not separable from a front-end capture. So the question is output versus data, and you choose based on how the new site will use it. WPBuildAI captures the rendered output for a faithful visual rebuild and, where you need the structured values, exports the custom field data so it can be re-templated on the new platform. ## Custom fields are data rendered into a template The reason custom fields need thought is where they live and how they appear. A custom field, whether a plain WordPress custom field or an ACF field, stores a value in the database attached to a post or page, and your theme templates pull that value in and render it into the visible page. So a product spec, a staff member's title, an event date, or a map coordinate is data behind the scenes that becomes ordinary-looking content on the page. That split, data underneath, rendered output on top, is the whole story of migrating custom fields, because it means there are two different things you might want to preserve, and they are captured in two different ways. ## Output versus data: the decision that drives everything The practical question is what the new site needs from those fields. If your goal is a faithful visual rebuild where pages look and read the same, then the rendered output is what matters, and a front-end capture already contains it, because the fields are baked into what visitors see. But if the new site needs the values as structured data, to power a filterable directory, a comparison table, a set of location pages, or any templated layout, then you need each field as a discrete value, which a capture of finished pages does not give you separately. So decide up front: are you preserving how it looks, or reusing the underlying data? That single decision determines whether capture is enough or an export is required, and getting it wrong in either direction wastes effort. ## When capture of the rendered output is enough For many sites, the rendered output is all you need. If custom fields were used to display a bit of extra information, a subtitle, a byline, a highlighted figure, and the new site will simply show the same thing, then capturing the live pages brings that content across as part of the visible text, and there is nothing extra to do. This is the common case, and it keeps the migration simple: the fields never have to be handled as separate data because their only job was to appear on the page, and the page is what you captured. It is the same logic that lets most content migrate by capture, and it fits the reassurance that [a rebuild does not need to import every underlying WordPress structure](/will-an-ai-website-builder-import-my-existing-content) to reproduce the site faithfully. ## When you must export the structured values The other case is real and worth taking seriously. When the field values drive functionality, not just display, you need them as structured data, and that means exporting from the source while you have access. The [WordPress REST API](https://developer.wordpress.org/rest-api/) can expose post metadata as structured JSON when configured, and export approaches can pull field values out as data, which overlaps with [exporting custom post types as JSON](/how-export-custom-post-types-wordpress-json) and the broader task of [extracting WordPress data without Python](/extract-wordpress-data-without-python). If your destination is a structured content platform, this is also how content maps cleanly when you [move to something like Sanity or Strapi](/migrate-wordpress-content-sanity-strapi). The point is that structured reuse requires structured export; you cannot reliably reconstruct clean field values from rendered pages after the fact. ## Do not lose the fields by assuming capture covers them The trap to avoid is assuming a visual capture preserves the data when you actually needed the data. If you plan to rebuild a filterable directory but only captured the finished pages, you have the appearance of the old directory without the values that made it filterable, and recovering them afterward is painful. So the safeguard is to make the output-versus-data decision before you migrate, and where data is needed, export it while your WordPress access is live. This is a content-integrity concern, not a rankings one, since the platform itself is not a ranking factor, as the [Backlinko analysis](https://backlinko.com/search-engine-ranking) shows, but losing structured data quietly undermines any feature that depended on it, which no [careful site move](https://developers.google.com/search/docs/crawling-indexing/site-move-with-url-changes) should allow. ## Steps to handle custom fields in a migration 1. **Inventory where custom fields and ACF are used**, and what they display. 2. **Decide output versus data** for each: faithful display, or reused structured values. 3. **For display only:** rely on capturing the rendered pages. 4. **For structured reuse:** export the field values via the REST API or an export tool. 5. **Do the structured export** while your WordPress access is still live. 6. **Verify on the new site** that both the appearance and any data-driven features work. ## Worked example: rebuilding a filterable directory Consider a site with a filterable member directory built on ACF, where each member had fields for region, specialty, and contact details, powering search and filters. A visual capture would have reproduced how the listing looked, but not the values that made filtering work. Recognizing this, the team exported the ACF data as structured JSON through the REST API while they still had access, so each member's fields came across as discrete values. On the new site they fed that data into new templates, rebuilding the directory with working filters. Because they made the output-versus-data decision before migrating and exported the structured values, the directory was fully functional after the move, not just a static picture of its former self. ## Limitation: complex field structures need mapping It is honest to bound this. Exporting field values is the right move for structured reuse, but complex ACF setups, repeaters, flexible content, relationship fields, and nested groups, do not always map cleanly to a new platform's content model, so they need deliberate mapping and testing rather than a blind import. The data can come across, but reshaping it to fit the new structure is real work, and heavily field-driven sites carry a lot of it, as the general growth in structured content reflected in [Web Almanac 2024](https://almanac.httparchive.org/en/2024/) suggests. So scope custom-field-heavy migrations honestly: simple display fields are trivial, but rich structured models deserve planning, not assumptions. ## Key points When you migrate off WordPress, custom fields and ACF data need a deliberate decision, because the values live in the database and are rendered into your templates, so migration depends on whether you need the rendered output or the structured data. For a faithful visual rebuild, a capture of the live pages already contains what the fields displayed, so there is nothing extra to do. To reuse the values as data, for a directory, spec table, or any templated feature, export the fields from the source through the REST API or an export tool, while your WordPress access is live. Make that output-versus-data call before migrating, since assuming capture covers data you actually needed is how field-driven features quietly break, and map complex field structures deliberately. WPBuildAI captures the rendered output for a faithful rebuild and exports the structured field data where you need it. Send your web address for a free analysis. Not affiliated with WordPress, Lovable, Webflow, Shopify, Wix, or Squarespace.