Magento is a powerful and popular ecommerce platform, however, there are many reasons to consider an alternative, such as WooCommerce.
Magento's great strength is its power and scalability, however it also has substantial drawbacks, not least of which is cost. Hosting alone for the Enterprise edition starts at $15,000 per year. Although it comes with full functionality out of the box, it is difficult and expensive to customise. WooCommerce is a plugin for the WordPress CMS (content management system) and is the core of a flexible and fully functional ecommerce ecosystem at a fraction of the cost of Magento. This blog post summarises a Magento to WooCommerce migration project I carried out, with an overview of the major issues involved.
Project overview
The store in question is STM Goods, which has been active for several years. A snapshot at the time of migration:
- STM Goods consists of two stores, serving the U.S. and Australia, on entirely separate domains, but sharing a common database.
- The store inventory comprises 197 products, each of which has multiple variations, all of which are separate SKUs.
- The stores have a total of over 8,000 existing orders.
Key challenges
- Converting Magento's schema – its database structure – to WordPress's
- Preserving multiple stores, with different currencies, shipping methods, and tax rates – connected to a single database
- Converting Magento's templates to WordPress's theme files
- Preserving the existing settings and customisations, including the mega menu, the variable product structure, the shipping, payment, and sales tax settings, and integration with the Netsuite back end
The Magento database – it's big
Before any conversion can begin, it's necessary to address the sheer size of the Magento database, which contains over 500 tables and is 12GB in size. A comparable WordPress database has 120 tables and is approximately 160MB, about 75 times smaller. Manipulating the database – sending it over the Internet, as well as performing any operations, such as importing or conversion – becomes a substantial task. Fortunately, a lot of this data can safely be discarded.
Magento generates many tables for routine tasks such as indexing, generating reports, and logging changes. These are not needed outside of Magento, and can be omitted from the initial data export. These include the following:
- Tables whose names begin with
enterprise_support,index_,log_,report_, andsales_flat_quote - Tables whose names end in
_cl
About 90 tables match these patterns, including the 9 biggest. Omitting them reduces the exported database file to 262MB, a 98% reduction. Still large, but manageable.
The import process
The design and structure of Magento and WooCommerce/WordPress are sufficiently different from each other that it's necessary to use third-party software to handle the database migration. There are two leading solutions, FG and Cart2cart, which use different approaches.
FG
FG Magento to WooCommerce is a WordPress plugin that handles the migration. It costs €100 (approximately $100) regardless of the size or complexity of your database. You set up a new WordPress installation, point it to the exported Magento database, and off you go.
Cart2cart
Cart2cart is a service that will take your Magento database, handle the migration for you, and send you the migrated WordPress database, ready for uploading to your server. The price of the service varies according to the size and complexity of the database. For this project, they quoted me $369.
I selected FG, partly because of lower cost, but also because it gave me more control over the process – if the initial import didn't go correctly, I could tweak the workflow and keep trying until I got it right. My concern with Cart2cart was, what would I do if there were significant omissions or errors in the import?
The import
Even with the radically trimmed Magento database, it was still necessary to make some adjustments to the server configuration in order to handle the import, and avoid running into memory, file size, or time limitations. Add (or edit) the following configuration values and restart your web and database servers:
- in MySQL's my.ini
- max_allowed_packet = 1000M;
- in php.ini
- post_max_size=1000M;
- upload_max_filesize=1000M;
- max_execution_time=72000;
- max_input_time=84000;
- memory_limit=1000M;
- in phpMyAdmin's config.inc.php
- $cfg['ExecTimeLimit'] = 6000;
- in WordPress's wp-config.php:
- define('WP_MEMORY_LIMIT', '1G');
Most standard shared web hosting plans won't allow you to make these changes, so you'll need to have your own local hosting environment (XAMPP or similar) to handle the migration, after which you can import the WordPress database to your production environment.
Even with these configuration changes, the FG plugin took hours to complete the import, during which it was necessary to restart the import several times. Note that FG will keep track of its progress, and will pick up the import from where it left off each time you restart.
Cleanup and configuration
Once the import is complete, you will need to inspect the database carefully for integrity and completeness. For instance, you may see some products that appear to be duplicates. FG handles naming conflicts by appending a digit to the slugs of products that it believes have already been imported, so watch out for sequences of products with the slugs my-product, my-product-1, my-product-2, and so on. The original product should always be assigned the optimised slug (my-product, in this case), and the duplicates deleted.
WooCommerce is designed to provide the minimal functionality necessary to get a basic ecommerce store up and running. Depending on the configuration of your Magento store, you will certainly need some additional plugins to replicate the original installation. These include:
- Plugins to support all your payment gateways and shipping methods
- If you have multiple stores connected to the same backend, as was the case with this project, the WooCommerce Multistore plugin, running on a WordPress Multisite installation, will be able to replicate this
You will need to recreate the design of your site using WordPress's theming functionality. The specifics of this will depend on the nature and complexity of your original design, and is beyond the scope of this blog post.