Migrating to Magento: what changes, whatever the original platform

Magento (Magento Open Source, and Adobe Commerce in its paid edition) is built for large catalogues, multi-store and multilingual sites. What makes it powerful also makes it demanding: moving to Magento means adopting its catalogue model, its URL format, its rewrite management and its extension ecosystem. These choices are the same whatever the original platform.

This page brings together what changes when you move to Magento. What is specific to the starting platform has its own article: migrating from PrestaShop to Magento and migrating from WooCommerce to Magento. The overall approach to changing platform is described in the CMS change procedure. For the SEO steps of any online shop, whatever its platform, see migrating an e-commerce website.

Magento stores product characteristics in attributes, grouped into attribute sets (one set per product family). A product with variants (size, colour) becomes a configurable product that carries simple products, one per variant. The other types (grouped product, bundle, virtual or downloadable product) have their own rules too.

Before any import, you therefore need to decide how the characteristics and variants of the old shop fit into this model: which attributes to create, which ones drive the navigation filters, which attribute set for each family. These decisions shape the import files and, later, the filter pages Google will be able to crawl.

Magento natively imports products, their advanced pricing and customers with their addresses, as CSV (System, Data Transfer, Import). Orders cannot be imported this way: their history goes through a migration tool or service, or stays available in the old system. The overall method is detailed in our article on e-commerce data migration.

Magento builds the address of a product or category from its URL key, followed by a suffix, .html by default, which can be changed in the catalogue configuration (Search Engine Optimization section). Another setting decides whether a product address includes the path of its categories. These settings must be decided before going live: changing them later alters every address in the catalogue.

The two questions to settle early:

• keeping addresses close to the old ones, by reusing the same slugs as URL keys: redirects are still needed as soon as the prefix or suffix changes, but the plan is easier to check;
• language: each language is a store view, with its own URL keys; a multilingual site needs one address per language and redirects per language.

Magento keeps a URL rewrite table: when you change the URL key of a product or category, it can create a permanent redirect from the old address on its own (a setting that is on by default). The admin also lets you add a rewrite by hand (Marketing, URL Rewrites). These mechanisms serve the everyday life of the catalogue; they know nothing about the addresses of the old platform.

For a migration, the hundreds or thousands of old addresses are better redirected at server level, in the .htaccess file or the web server configuration, before Magento handles the request. The three methods, and their exact place in Magento's .htaccess, are detailed in our article on redirects in Magento.

The modules of the old platform do not carry over: each function (payment, shipping, reviews, loyalty, search) has to be found in a Magento extension or developed. The theme has to be rebuilt, and any custom code rewritten. Hosting must keep up: Magento needs more resources than most platforms, a dedicated search engine (OpenSearch or Elasticsearch), and properly configured scheduled tasks and cache.

List the functions of the current shop before choosing extensions: a forgotten function is often discovered after going live, by a customer.

Swan crawls the old shop and the Magento staging site, matches each old URL with the Magento page that corresponds to it by semantic proximity of the content, has you validate the doubtful cases, checks the redirects on staging and then in production, and exports them as .htaccess or CSV. You also import the URLs from Search Console and your own URL lists (backlinks, logs) so that no address that matters is left without a destination.