Migrate from Magento to fabric

In this guide, we outline some of the reasons your team might consider the move from Magento to e-commerce microservices and the steps you can take to start this migration. Along the way, you’ll see which elements of Magento you might replace first and some options in case you don’t want to build all of your microservices from scratch.

Why Microservices over Magento?

• Security: Magento—especially the self-managed, open source version—has always been a security nightmare. Sixty-two percent of Magento stores operating today have an unaddressed security vulnerability which might leave customer or company data vulnerable to hackers.
• Technical Complexity: For many e-commerce stores, Magento adds a lot of overhead that probably isn’t necessary. For example, instead of adding attributes directly to products, developers have to hook into its EAV model to add product features. This slows down development and means deep, Magento-specific knowledge is required.
• Flexibility: As with all monolithic platforms, it can be hard to granularly scale Magento as your e-commerce application grows. Installations are typically made on a single server, and Magento doesn’t give you much room to swap out databases or add caching layers based on your needs.

Planning the Magento Migration

While the exact process you use will vary depending on whether you’re using the open source or hosted version of Magento and how many extensions you’re using, the following is a general look at the steps you’ll need to take during your migration.

One of the hardest parts about unraveling a monolith is deciding where to start. There are two approaches that teams typically take.

• Start with the area that’s easiest to separate and migrate. For example, if you have product reviews on your Magento site and they’re decoupled from the core product data, you might want to start here. Migrating product reviews to a new microservice will help you get the process started, but it probably doesn’t provide a ton of value to your business (unless product reviews happened to be limiting growth).
• Start with the area that provides the most business value. If you’re trying to improve your store’s conversion rate, you might want to start with the checkout. If you’re trying to improve signup and authentication, you might start with an authentication microservice. By commencing your microservice migration with the investment that brings the most business value, you’ll build trust and give leadership a reason to continue investing in the process.

You’ll likely want to make requests to Magento from your new microservices or new user interface during your migration. In this case, an API abstraction layer is likely a good investment.

This piece—sometimes called an API gateway—acts as a router to pass all requests to either the monolith or microservices and allows you to run both in tandem while you migrate.

Another element you’ll need to build as you migrate more of your functionality to microservices is a service mesh. Your service mesh handles some of the shared operational functions typically absent from microservices (e.g., logging, load balancing, routing) and helps minimize the need to duplicate functions like authentication or authorization between services.

You’ll likely have to write some custom PHP or SQL code to export much of your data from Magento. Because of Magento’s complex EAV table system, it’s much easier to export data if you first switch to their flat catalog. After that, your product catalog will be cached into a single flat table which is easier to export and query against.

Next, you have to export data for orders, customers, carts, etc. Doing so will be a tedious process as each requires its own SQL query. For example, this query will get your orders with their payment and shipment IDs:

SELECT sales\_order.entity\_id AS Order ID",

sales\_order\_payment.entity\_id AS "Payment ID",

sales\_shipment.entity\_id AS "Shipment ID"

FROM sales\_order

LEFT JOIN sales\_order\_payment ON (sales\_order.entity\_id = sales\_order\_payment.parent\_id)

LEFT JOIN sales\_shipment ON (sales\_order.entity\_id = sales\_shipment.entity\_id)

# Note: you can add any filters as WHERE queries here

ORDER BY sales\_order.created\_at

Now you can export each of these query results to a .csv file and import them into your new microservice. This import process will vary depending on the language of your new service and shape of your new database, but it could be a simple Node script. The following example uses the popular csv-parse package.

const db = require('./database');

const fs = require('fs');

const parse = require('csv-parse');

const parser = parse({columns: true}, function (err, orders) {
  orders.forEach(function (order) {
    // You can transform your data or save it here
    db.save(order);
  });
});
fs.createReadStream(\_\_dirname+'/orders.csv').pipe(parser);

If you want to run both Magento and your new service in tandem, you’ll need to set up a data pipeline so that records are piped to your new microservice whenever they are added. MySQL doesn’t support triggers on views, so you’ll have to set up a service to check for updates and pipe them over to your new database.

Note: This article only begins to tell the story of migrating from Magento to microservices-based commerce with fabric. We are currently creating a Magento migration playbook with more detailed information.