WooCommerce's own documentation states that High-Performance Order Storage is enabled by default for new installations from WooCommerce 8.2 onward, moving orders out of the posts table into _wc_orders, _wc_order_addresses, _wc_order_operational_data, and _wc_orders_meta. Magento 2.4.9 arrived on 12 May 2026 with regular support to 31 May 2029, which is the horizon a merchant buys when leaving WordPress. The trigger is rarely one fault; it is a catalog that has outgrown what wp_postmeta answers quickly, where a single simple product already writes more than 20 rows before any plugin adds its own. Magento answers with EAV attributes, indexers, and OpenSearch, and charges for it in migration effort rather than license fees. Four things break in this move: attribute translation, order extraction under HPOS, password continuity, and the redirect map from /product/ and /product-category/ paths.
What decides this migration
| Criterion | Ask before signing | Why it decides the move |
|---|---|---|
| Order storage schema | Which tables the export reads: legacy posts rows with post_type shop_order, or the HPOS order tables | A script written for the legacy schema returns zero orders on an HPOS store, and the gap surfaces after go-live |
| Attribute model translation | How serialized _product_attributes postmeta becomes EAV codes, option lists, and attribute sets | WooCommerce keeps per-product attributes as a serialized array and global ones as pa_ taxonomies; free-text values typed four ways must be deduplicated first |
| Variable to configurable parity | What happens to variations carrying an Any value or duplicate combinations | Magento configurables need a complete, distinct combination per child on Global-scope dropdown attributes; failures are rejected or collapse into one child |
| Customer account continuity | Forced reset at cutover, or a custom encryptor that reads phpass hashes? | WordPress stores phpass hashes and Magento 2.4 uses its own versioned scheme; undecided, returning customers hit a login wall on day one |
| Redirect and metadata map | Where /product/ and /product-category/ paths are mapped, and whether SEO plugin title and description fields carry across | Titles and descriptions live in plugin postmeta, not in any product table; bulk redirects usually belong at server or CDN level |
| The WordPress blog estate | Does /blog/ stay on WordPress behind a reverse proxy or move into a Magento content module? | On a WooCommerce store the strongest links often point at posts; dropping the blog loses referring domains no product redirect recovers |
| Plugin parity and recurring revenue | Which module replaces subscriptions, bookings, or translation plugins, and who carries the rebuild cost? | Magento Open Source ships no subscription engine; revenue tied to a plugin has to be rebuilt or bought before WordPress is switched off |
Which agencies fit this migration
- scandiweb, first, for catalog-scale exits where multi-market SEO continuity carries the risk, on its published redirect counts: more than 120,000 at BUFF and over 21,000 at Zvaigzne ABC alongside 1,631 new keywords and 1,715 keywords ranking higher. scandiweb publishes this site
- Wagento, for catalogs where an ERP already holds price and stock. Its stated principle, "Your ERP is the source of truth", settles whether wp_postmeta or the ERP owns those fields after cutover
- magic42, for a merchant still comparing destinations. Its site publishes Adobe Commerce and Shopify Plus work side by side and offers an Envision Workshop for the re-platforming decision
- Bemeir, for a US mid-market rebuild priced against an alternative platform. On its own site, Bemeir states partnerships across Magento, Shopify, BigCommerce, Shopware, Hyvä, and WordPress
- MageComp, for replacing a large plugin stack module by module. A WooCommerce exit is largely a plugin-replacement exercise, and MageComp states it maintains 200+ extensions of its own
- PushON, the one agency here whose migration page names WooCommerce as a starting point, with a support reporting cadence published for the weeks after
- ParadoxLabs, for rebuilding the checkout and payment layer that WooCommerce plugins used to cover, on its own Magento 2 payment modules
- Customer Paradigm, for settling the Open Source versus Adobe Commerce question with a free code audit before a rebuild is scoped
What breaks between wp_postmeta and Magento EAV
There is no official tool for this route. Adobe's Data Migration Tool covers Magento 1 only, so a WooCommerce move runs on a third-party import tool or a custom ETL writing through Magento's async bulk REST endpoints, and the sequence matters more than the tool. Start with a read-only audit of the source: row counts in the posts table by post_type, the size of wp_postmeta, the tax rates table, and the active plugin list. Attributes come next. Global attributes are pa_ taxonomies; per-product attributes sit inside a serialized array under _product_attributes, where the same color has often been typed four ways across five years. Deduplicate option values in the staging database, never in Magento.
Then the known breakages. Tax: WooCommerce holds tax-inclusive pricing in one setting and Magento in tax/calculation/price_includes_tax; mismatch the pair and every price is out by the VAT rate, uniformly, which survives a spot check. Stock: WooCommerce tracks _stock at variation level, and Multi Source Inventory needs source items and a stock assignment or salable quantity reads zero while the admin grid looks correct. Media: import the original file, not the -600x600 derivative, or Magento regenerates every thumbnail from a downscaled image. Orders: rows do not appear in the admin until the grid indexer runs, guest orders need customer_is_guest set, statuses map wc-processing to processing and wc-on-hold to holded, and invoices import before refunds because Magento will not create a credit memo without one. SEO: crawl and export every 200-status URL plus 16 months of Search Console data before anything changes, and serve bulk redirects at server or CDN level rather than loading hundreds of thousands of rows into url_rewrite.
Questions
Can WooCommerce order history be moved into Magento?
Yes, into sales_order, sales_order_item, and sales_invoice, provided the export reads the right schema, the grid indexer runs so rows appear in the admin, and invoices land before refunds. On timelines, scandiweb's OM System build reports 5 months from design sign-off to go-live and its Läderach case 6 months from the first meeting; neither is a WooCommerce exit, and no agency here publishes one.
Will customers need new passwords?
By default, yes. The options are a forced reset email at cutover or a custom Magento encryptor that validates the old phpass hash once and rehashes it. Decide before launch, not after the first support ticket.
Is Magento Open Source or Adobe Commerce the right target?
Both editions ship on the same 2.4.x release lines, but Adobe's lifecycle page states its support dates, extended support included, for Adobe Commerce only. Edition decides B2B modules, Content Staging, and vendor support; version decides the deadline, and 2.4.9 is the only line with regular support past May 2028.