WoodMart plugin compatibility audit before headless migration

Every plugin on a WoodMart store falls into one of two buckets. Backend/data plugins (inventory, tax, shipping, ERP sync, most payment gateways) run inside WooCommerce and are unaffected by a new frontend. Frontend-rendering plugins (layered filters, review widgets, wishlist, currency switchers, some page-builder add-ons) inject HTML/JS into the theme — those are the ones that need attention.

We go through the active plugin list and classify each one:

• Backend-safe: keeps working unchanged in WooCommerce
• Has an API/headless mode we can consume directly
• Needs a component replacement on the new storefront
• Frontend-only with no clean path — flagged before you commit

Payment, tax and shipping plugins are the scariest to migrate — so by default we don't. Keeping native WooCommerce checkout means those plugins keep running exactly as they do now, which removes most of the compatibility risk on day one.

For plugins that only render UI — filters, reviews, wishlist, swatches — we rebuild the feature as a native storefront component reading the same WooCommerce data. Shoppers get the same capability, usually faster, without the plugin's frontend weight.

In practice the same families of plugins show up on most WoodMart stores, and each has a known classification. Translation plugins like WPML and Polylang are data-level and read cleanly through the API. YITH and similar add-ons for wishlist, compare and badges are frontend-rendering and usually rebuilt as components. Review platforms such as Judge.me or Yotpo often expose their own API or widget that can be consumed directly. Points-and-rewards, product add-on and subscription plugins are the ones to examine most carefully, because they touch both data and the buying flow. Knowing which bucket each falls into up front is what turns a scary plugin list into a plan.

• Multilingual (WPML, Polylang): data-level, read through the API
• Wishlist, compare, badges (YITH and similar): rebuilt as components
• Reviews (Judge.me, Yotpo): often consumed via their own API/widget
• Points, add-ons, subscriptions: examined closely because they touch checkout

Classification is a plan; staging is the proof. We stand up the new storefront against a copy of the store and exercise each frontend-affecting plugin in place: does the wishlist add and persist, do reviews render and submit, does a subscription product reach checkout correctly, does multilingual switching resolve the right URLs. Backend plugins are verified by placing real test orders and confirming the data flows through WooCommerce untouched. Nothing is assumed compatible because a vendor says so — it is confirmed on staging before the domain switches.

Not every frontend plugin has to be rebuilt — some are already headless-friendly. A growing number of WooCommerce plugins expose their own REST or GraphQL endpoints, or a documented data layer, precisely so a decoupled frontend can consume them. When that is the case, the storefront reads the plugin's data directly and renders it in a native component, which keeps the feature and its data without loading the plugin's own scripts. Part of the compatibility audit is simply checking, for each frontend plugin, whether an API already exists before assuming a rebuild — it is often the cheapest path of all.

• Some plugins expose REST/GraphQL or a documented data layer
• The storefront can consume that directly, without plugin scripts
• Check for an existing API before assuming a rebuild
• It is often the cheapest compatibility path

If a critical plugin has no clean headless path, we tell you before any paid work — that's the point of the audit. Sometimes the right answer is to optimize WoodMart instead, and we'll say so rather than sell a migration that would break something you depend on.