Magento to Vendure

Why they left

The client's initial request was direct: they wanted to move away from the bloat, lack of speed and restrictions they were experiencing in their Magento 2 setup. They also wanted a long-term development partner. This wasn't a shop they expected to finish and leave untouched.

The clearest practical problem was pricing maintenance. Many products were priced by area: height × width, multiplied by a square-metre rate, with further calculations for product options. General and wholesale customers needed different prices.

Their existing pricing plugin worked. It gave them considerable flexibility. But changing prices meant editing products individually. That was time-consuming for a business that regularly adjusted its catalogue and pricing.

Magento 2 had supported a functioning business with this custom logic and it worked, but this implementation had become difficult to maintain. This helped us shape our plan: preserve the useful business data and behaviour, but don't reproduce every old implementation decision.

Pricing they could maintain in a spreadsheet

The client wanted to manage pricing through Google Sheets instead. Updating rates in a spreadsheet was a better fit for their daily work than repeatedly opening individual product configurations.

Delivery added another layer

Large-format printing doesn't fit neatly into a flat shipping charge. Dimensions, weight and total area can matter, and a dedicated vehicle needs a distance-based calculation.

What we were actually moving

The data migration covered customers, orders, blogs and product content. Product names, descriptions and slugs were part of the export. Keeping existing slugs mattered because we wanted established product URLs to survive the move.

The more difficult inventory was the product configuration. A banner isn't necessarily one variant with one price. The customer supplies dimensions and chooses options, and those inputs determine what it costs. The old plugin's configuration didn't map directly onto our new model.

We therefore treated product content and product behaviour as separate pieces of work. Content could be imported. Configurable options needed to be redesigned and manually defined in the new system.

Historical orders needed their own decisions. We migrated order line data, prices and address details, but did not reconstruct the original Magento promotions as Vendure promotions. Preserving what the customer ordered and the recorded prices was more valuable than recreating the rules that had produced every historical discount.

What the first storefront launched with

• Google Sheets pricing integration.
• Different pricing for general and wholesale customers.
• Purchase-order checkout for authorised credit-account customers, built as a custom payment method.
• Distance-based shipping calculations.
• Mollie for payments.

Blogs moved into Directus, while the storefront was rebuilt in Astro. We launched Colour Graphics first and moved Fabrix later, using Vendure channels to support multiple storefronts.

Separate content from business rules

We started with a vanilla Vendure instance and exported the existing Magento data. We wrote import scripts for customers, orders and product content. Blog and product content exports used CSV, and blogs were imported into Directus.

Customers, blogs and product content were relatively straightforward. The surprise was how little of the configurable-product setup could sensibly be treated as ordinary migration data. Importing a calculation isn't enough if the new application interprets product options differently.

Data migration represented about 20% of the overall effort. Across a roughly 400-hour project, that's around 80 hours. These are approximate allocations, not separate calendar phases: the work overlapped.

Today, we would manage blogs with our CMS plugin within Vendure's React Dashboard instead of maintaining Directus as a separate content system.

Rebuild the calculations, then cut over

Another roughly 40% went into backend configuration, configurable products and integrations.

For calculated product prices, we implemented Vendure's OrderItemPriceCalculationStrategy. In our implementation, the strategy reads the selected configuration, calls the calculation service and returns the appropriate trade or retail price. Products without a configurator use the default pricing strategy.

This gave the calculations an explicit place in the backend rather than carrying over the Magento plugin model. We also connected Google Sheets pricing, purchase-order checkout, distance-based shipping and Mollie payments.

Checking every URL before launch

Before launch, we compared URLs on the live site with those on the development site using Linkinator. Some products had been removed and some categories renamed or reordered. We created redirects for missing or moved pages rather than assuming preserved product slugs covered everything.

Going live, then importing the order delta

We went live with Colour Graphics first, then migrated the delta of orders placed since the earlier export. Active carts were not migrated. The Fabrix storefront followed later rather than making the first cutover a multi-brand launch.