Migrate from WooCommerce to Magento Open Source

The product CSV is the handover file between the two platforms, so the mapping work decides how much of the catalog arrives intact. WooCommerce ships a product CSV exporter in core. It sits under Products, All Products, Export, and it can limit the export to selected product types and categories. It writes product images as URLs rather than embedding files, which means the image host has to stay reachable during the migration. Start by exporting a small, representative set of simple, variable and grouped products, then open the file and list every header. That header list is the starting point for the column map. Build the column map before you touch Magento. Create a spreadsheet with three columns: the WooCommerce header, the Magento import column it feeds, and the transformation applied. Take the Magento product import template from the Magento version you run, not from an older guide or a blog post. Column names, required fields and the accepted format for attributes can change between 2.4.x releases, so confirm each template column against your installed version. Mark every WooCommerce header as mapped, transformed, dropped or pending a decision. Headers with no destination are the ones that get lost silently if nobody reviews them.

Categories need their own decision. WooCommerce category paths are hierarchical and use a separator in a single column, while the Magento import expects category paths in its own format and the target category tree must already exist or be created first. Decide whether the category tree is rebuilt in Magento before the import, and whether category names are kept, slugged or renamed. Attributes follow the same pattern. Global attributes in WooCommerce (for example, colour or size) have to map to Magento attributes with matching codes and option values, and any attribute that Magento does not define needs to be created first. Custom product fields, often added by plugins or theme code, have no default destination. Each one needs a named Magento attribute, a decision to drop it, or a custom import step. Variations need the most attention. WooCommerce variable products store each variation as a separate row, and the Magento side expects configurable products with child simple products. The WooCommerce product CSV documentation notes that variation names may omit attribute values in some cases, particularly when products have three or more attributes. Do not rely on the variation name to recover the option values. Check the attribute columns for each child row, and confirm that every child has a SKU that is unique across the whole catalog. Plan the grouping logic as a separate test case, because a configurable product built from incomplete child data will import without a warning and only fail when a shopper selects an option.

Cleaning and enrichment decisions belong in the plan too. Strip HTML that your Magento theme will not render, normalize currency and decimal formats, trim whitespace from SKUs, and decide how to handle products with no image, no stock quantity or missing descriptions. Enrichment, such as adding meta titles, tax classes or inventory sources that WooCommerce did not hold, can be done in the file or after import, and each choice should be written down. Expect the image URL step to be the first to fail if the source host is removed or blocks requests, so download and verify images as a separate check. Test on a copy of the catalog. Run the full mapping against a copy of the Magento store, not the production instance, and compare counts, SKUs, categories, prices and variation options against the WooCommerce source. Keep the column map and the cleanup scripts under version control so the second and third runs produce the same result. Ask your implementation partner, or your own team, to confirm the exact template columns for your Magento release and to document every header that was dropped or changed.

The product CSV and the product import cover catalog data only. They do not carry the full order history, payment records, refunds or fulfillment state from WooCommerce, so the team has to decide early what historical data it must keep, in what form, and where it will live after cutover. Treat this as its own workstream with an owner, because the answer shapes the legal retention plan, the finance reconciliation and the customer service tooling that staff will use on day one.

The customer import is the documented path for account data, but it is not a full copy of a WooCommerce customer record. Passwords are the main trade-off. Password hashes generally cannot be moved between platforms with different hashing schemes, so the usual approach is to import accounts and force a reset or a one-time login flow for customers. Addresses need field mapping and validation, and marketing consent needs a deliberate decision: consent records should only be carried across when the team can show where each opt-in came from and that it still applies to the new store. Confirm the exact customer import fields, password handling and address format against the documentation for the Magento Open Source version you will run.

Several methods are realistic, and each has different costs. The first is keeping WooCommerce running read-only for order history, which preserves the original records and avoids rebuilding history in a new system, but it means maintaining a second application, its hosting, its database and its security patches for as long as the history is needed. The second is archiving orders in a separate store, such as a database or document repository with search, which is cheaper to run but means customer service and finance will work from a different tool. The third is a controlled import of orders into Magento with DeployOpen's developers, which gives the team a single system of record but requires mapping order states, payment references, refunds and tax lines, and testing each of them.

The right choice depends on two questions that the business must answer before technical work starts: how long the law and the company's retention schedule require each type of order and payment data to be kept and who must be able to retrieve it, and which reports finance, tax and operations need to run against historical orders. Ask your legal, privacy and finance owners to write these requirements down, then compare the three methods against them. Whichever method you choose, confirm each step against the documentation for your target Magento Open Source release line, and have a test restore or reconciliation run that proves the historical data can be found and explained after cutover.

The target environment has to be settled before any product row is loaded, because the import, the attribute model and the indexers all run on a specific Magento version and server stack. The first decision is the release line. Adobe gives each 2.4.x release three years of standard support from general availability, with end of regular support on August 11, 2026 for 2.4.6, May 31, 2027 for 2.4.7, May 31, 2028 for 2.4.8 and May 31, 2029 for 2.4.9. Measure those dates against your launch plan and your expected patch effort. Before you choose a line, confirm its current release status on Adobe's released versions page, because the status of each line changes over time.

For the 2.4.9 line, Adobe's system requirements list PHP 8.5, MySQL 8.4 or MariaDB 12.3 (recommended) or MariaDB 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30, all on Linux x86-64. Adobe supports only the listed combinations, so a newer database build, a different PHP minor version or an unlisted search engine places the store outside support. Requirements change between lines. The 2.4.8-p5 list, for example, names PHP 8.4 or 8.3 and Redis or Valkey 8.1, so do not carry values from one line to another. Build the staging server from the requirements page for the line you chose, and record each version in your decision log.

Adobe documents Varnish as the full-page cache accelerator for self-managed installations. Decide whether Varnish will sit in front of nginx on your servers, which Varnish version the chosen line requires, and who owns its configuration and purge behavior. Catalog imports trigger cache invalidation, so an unplanned cache layer can show old prices or stock levels during testing and confuse the results. If you plan a cloud-hosted Adobe Commerce deployment instead, Adobe documents Fastly for that case, so this decision does not apply in the same way. Confirm the cache design with the team that will run the servers before the first test import.

Content Security Policy headers are supported from version 2.3.5, and from 2.4.7 the policy runs in restrict mode by default on storefront and admin payment pages. A WooCommerce store often loads scripts from its old theme, analytics tags, reviews widgets and payment plugins, and any of them can be blocked once the policy is enforced. Inventory every external script and frame source the old store uses, then decide which ones the new theme will keep and which origins they need. Test the checkout and admin payment screens on staging under restrict mode before cutover, and record the approved sources as part of the launch evidence.