Magento Ombouwen naar WooCommerce: The Data Model Translation You Can't Skip

Rebuilding a Magento store in WooCommerce is not a lift-and-shift. The two platforms store product data in fundamentally different ways, and that gap is where most migrations stall. Get the data model translation right first, and the rest of the project follows a clear path.

Key takeaways

• Magento's EAV database (Entity-Attribute-Value) stores each product attribute as its own row; WooCommerce stores it in serialized wp_postmeta strings. The formats cannot be directly imported.
• Magento configurable products (parent + child) map to WooCommerce variable products, but the transform must preserve every attribute, variation SKU, stock level, and price delta.
• Adobe Commerce 2.4.4 and 2.4.5 are past both standard and extended support as of 2026; stores on these versions now receive security-only patches until May 2027, making migration timing urgent.
• WooCommerce 11.2.0 (released October 7, 2026) updated the Product CSV importer to match rows by GTIN, UPC, EAN, or ISBN when no SKU is present, which directly benefits Magento migrations with inconsistent SKU coverage.
• Run a demo migration on 10-20 products before committing to a full run; every tool surfaces column-mapping errors at this stage, not after 40,000 rows are in.

Why stores are making the move right now

The pressure to leave Magento Open Source is concrete and time-bound. Adobe Commerce 2.4.4 lost standard support in April 2025 and extended support in April 2026. Version 2.4.5 followed: standard support ended August 2025, extended support in August 2026. Both lines now sit in a security-only window that runs until May 31, 2027, after which even isolated security patches stop. PHP 8.1, which powers those versions, reached end of life on December 31, 2025, putting PCI compliance directly at risk for stores that have not moved.

On the cost side, Adobe's enterprise licensing for the commercial edition has escalated significantly, with mid-market estimates running from roughly $22,000 to over $100,000 per year. WooCommerce's open-source model is a legitimate alternative for stores that do not need the B2B complexity Magento was purpose-built for.

The core problem: EAV vs. postmeta

Magento stores product data in an Entity-Attribute-Value schema. Every custom attribute lives as its own row in tables like catalog_product_entity_varchar, catalog_product_entity_decimal, and so on. A single product with 30 attributes generates 30+ rows across multiple tables before you touch variants.

WooCommerce stores the equivalent data in wp_postmeta as serialized PHP arrays keyed under _product_attributes, _price, _sku, and similar meta keys. The shape of the data is completely different.

This means no migration tool can simply SELECT from Magento and INSERT into WordPress. Every tool on the market (LitExtension, Cart2Cart, FG Magento to WooCommerce, or the official WooCommerce Magento Migration plugin) runs a transform layer in between. Understanding what that layer does, and where it breaks, is the job of the developer running the project.

The configurable-to-variable product problem

This is where most migrations produce silent errors that only surface in production.

In Magento, a configurable product is a parent entity with associated simple child products. The parent holds presentation data and shared attributes. Each child holds its own SKU, price, stock level, weight, and any variation-specific overrides. The relationship is stored in catalog_product_relation.

In WooCommerce, the equivalent is a variable product with variations. Each variation is a post of type product_variation, a child of the parent product post. Attributes are stored as product taxonomies (pa_color, pa_size) and the variation inherits or overrides the parent's attributes through term metadata.

The transform must do all of this:

• Create the WooCommerce parent variable product
• Create a pa_ taxonomy term for each Magento attribute used in configuration
• Create one product_variation post per Magento child
• Map the child's Magento SKU, price, stock quantity, and images to the variation
• Set the variation's attribute terms to match the Magento child's option values
• Flag the parent product as manage_stock = no and set manage_stock = yes on each variation if Magento managed stock at the child level (which it usually does)

If any step is skipped, the variation exists in the database but the WooCommerce front end either cannot render the attribute selector or cannot add the correct variation to cart.

Verification query after import:

SELECT p.ID, p.post_title, COUNT(v.ID) AS variation_count
FROM wp_posts p
LEFT JOIN wp_posts v ON v.post_parent = p.ID AND v.post_type = 'product_variation'
WHERE p.post_type = 'product' AND p.post_status = 'publish'
GROUP BY p.ID
HAVING variation_count = 0
ORDER BY p.post_title;

Any row this returns is a variable product with zero variations. Go fix those before launch.

Migration approach comparison

The data you must transform manually, regardless of tool

No automated tool handles these correctly out of the box:

• Magento bundle products have no direct WooCommerce equivalent. Options include WooCommerce composite products (via a paid plugin), grouped products, or a structural simplification decision. Make this call before migration starts.
• Customer groups and tier pricing. Magento customer groups with group-specific pricing require a WooCommerce membership or wholesale plugin post-migration. The pricing rows will not transfer; they need to be rebuilt.
• CMS pages and blocks. Magento's CMS content is not e-commerce data. It does not import via any migration tool. Export manually, reformat for the WordPress block editor (Gutenberg), and import as pages.
• Product reviews. Native review exports are unreliable across the tool ecosystem. If reviews are business-critical, plan a custom export from Magento's review and review_detail tables and import via the WooCommerce REST API's /wc/v3/products/{id}/reviews endpoint.

Redirect strategy: the part that kills SEO

Magento URLs follow a pattern like /category/subcategory/product-name.html. WooCommerce defaults to /product/product-name/. Every URL change without a matching 301 redirect is organic traffic walking out the door permanently.

Before you cut DNS:

1. Crawl the live Magento store with Screaming Frog and export all indexable URLs.
2. Build a redirect map pairing each Magento URL with its WooCommerce equivalent.
3. Import the map into Nginx or Apache rewrite rules, or use a plugin like Redirection if you are on managed hosting that does not allow server config changes.
4. After launch, pull Google Search Console's Coverage report within 48 hours. Any spike in 404s that were not there before launch is a redirect gap.

Category URLs are the most commonly missed. Magento's layered navigation creates URLs like /clothing/jackets/color/blue.html that are indexed, get traffic, and have no WooCommerce equivalent at all. These need to redirect to the base category, not a 404.

WooCommerce 11.2 changes one import detail

WooCommerce 11.2.0, released October 7, 2026, updated the Product CSV importer to match rows by GTIN, UPC, EAN, or ISBN when no ID or SKU is present, with the match order being ID first, then SKU, then global unique identifier. A non-blank identifier that matches nothing skips the row rather than creating a duplicate product.

This matters for Magento migrations where the source catalog uses EAN/GTIN as the primary product identifier instead of a structured SKU. Previously, missing SKUs caused silent duplicate creation. Now the importer refuses the row, which is easier to catch and fix.

For further context on WooCommerce's postmeta data model, see the glossary entry on postmeta and product data.

Pre-launch validation checklist

Run these checks on staging before touching DNS:

• Spot-check 10% of products: names, prices, SKUs, stock quantities, categories, and images
• Add each product type (simple, variable, grouped) to cart and complete a test checkout
• Verify all variable product attribute selectors render correctly and update price on selection
• Confirm order history is accessible in customer accounts (even if read-only)
• Confirm payment gateway credentials are live, not staging keys
• Place a real test order and verify the fulfillment email fires
• Check Google Analytics / GA4 data layer is firing on purchase confirmation
• Run the 301 redirect map against the Screaming Frog crawl export and confirm zero gaps

The migration that does not get caught by this list before launch will be caught by customers after it. The list is faster.