Migrating from WPML Advanced Builder to the New WPML Translation Workflow

Support
#1

Hi,

Our site has been using Cornerstone + WPML for many years. We currently have WPML Advanced Builder enabled , which allows us to edit the English and Hebrew versions separately in Cornerstone.

Most of our site consists of WooCommerce product pages rather than standard WordPress pages . Our products have separate English and Hebrew translations linked through WPML/WooCommerce Multilingual, and the product content/pages have also been built using Cornerstone.

I understand that WPML Advanced Builder is now deprecated and that Themeco recommends moving to the newer WPML Translation Management / Advanced Translation Editor and String Translation workflow, with Locale Conditions where language-specific layouts are required.

Before changing anything, we would like to understand the officially supported migration path for an established WooCommerce + WPML + Cornerstone site .

Specifically:

  1. Is there an official migration procedure for an existing site built using WPML Advanced Builder?
  2. If we disable WPML Advanced Builder, what happens to the existing English and Hebrew Cornerstone builder data? Is all of the existing content preserved?
  3. Can existing English/Hebrew Cornerstone pairs be converted to the new Translation Management / Advanced Translation Editor workflow, or do the translations need to be recreated?
  4. Is there an automated migration/conversion process, or does this need to be done manually for each page/product?
  5. How does the new workflow apply specifically to WooCommerce products? Our English and Hebrew products exist as separate WPML-linked WooCommerce product records. Do those records continue to work in the same way through WPML/WooCommerce Multilingual, while only the Cornerstone content moves to the new translation workflow?
  6. If both the English and Hebrew product records currently contain their own Cornerstone builder data created under Advanced Builder, is there a supported way to migrate that existing builder content without manually rebuilding all of our translated products?
  7. For pages or products where the English and Hebrew Cornerstone layouts are genuinely different, is the recommended replacement to use Locale Conditions within a single Cornerstone document ?
  8. What is the safest procedure for migrating an existing production site without losing any of the current Hebrew content, product translations, or Cornerstone layouts?

We have also reviewed WPML’s current documentation. WPML’s recommended WooCommerce workflow appears to be translating products through the WPML Translation Dashboard, while maintaining the translated products as separate WPML-linked WooCommerce product records. WPML also continues to document Cornerstone as a supported page builder whose translatable builder fields can be exposed to the WPML Translation Editor. What we have not been able to find is a documented migration procedure for existing Cornerstone content that was created using Themeco’s legacy WPML Advanced Builder workflow.

We will, of course, test any migration on staging first. We mainly want to make sure we understand Themeco’s intended migration path before disabling Advanced Builder or attempting to convert any existing Cornerstone/WPML data ourselves.

Thank you

#2

Hello @ywoolf,

Thank you for the detailed description. I understand you want to move existing Cornerstone content translated through the legacy WPML Advanced Builder workflow to the current WPML workflow without losing translations. Please review the points below.

Quick Check

  • Confirm PHP version is 8.1+.
  • Confirm both Pro/X and Cornerstone are updated to the latest versions.

Troubleshooting

  1. No migration is required – There is no conversion procedure because no data changes. Each translated page or product is already its own post with its own builder data. The WPML Advanced Builder toggle in Cornerstone > Settings > Advanced only controls whether translated posts can be opened inside Cornerstone. Switching it off deletes or alters nothing and is reversible, and existing sites may keep using it.

  2. Use the current workflow for content you edit going forward – Where the translation mirrors the source, edit the English document and translate text through WPML > Translation Management. Where the Hebrew layout is genuinely different, build both variants in the single English document and wrap each in a Locale condition. WooCommerce products and product layouts follow the same pattern.

  3. Test on staging first – Take a backup, switch the toggle off on a staging copy, confirm existing Hebrew pages and products still render, and trial both paths from step 2 on one page and one product. Move pages to the new workflow only as you next edit them.

Best Regards.