Leaving Magento in 2026: Upgrade, Shopify Plus or Custom Laravel?

After years of working with stores that outgrew Magento, we have become more selective about recommending another Magento installation. Here is how we compare the three options, and why for many stores the answer is Laravel.

SHORT ANSWER

The Short Answer

A store leaving an old Magento version has three realistic options: upgrade Magento, move to Shopify Plus, or move to a custom platform built on Laravel. For a standard direct-to-consumer store selling in one or two markets, Shopify Plus is often the simplest choice. For a very large catalogue with many store views and native Adobe B2B features, staying on Magento can make sense. For stores with their own pricing, delivery rules, several markets or many integrations, we recommend Laravel more often than either.

The strongest argument for Laravel is the ability to build the system around the way a specific business works and to keep control of what it costs to change it later. The missing licence fee helps, AI makes custom development more affordable, and owning the code gives more control, yet none of these on its own guarantees a lower cost of ownership. What decides it is how the three work together over the next five years.

DEADLINES

The Dates Behind the Decision

The question is urgent for many stores because of Adobe's support calendar. Standard support for Magento 2.4.6 ended on 11 August 2026. For 2.4.7, standard support ends on 31 May 2027. Newer versions, 2.4.8 and 2.4.9, are supported until 2028 and 2029, so Magento as a platform is not going away; what ends is support for the version a store is running. Every store on an older version therefore faces a project either way: an upgrade or a move.

There is also a fair argument for staying. In November 2025 the Hyvä theme, the most popular way to make a Magento storefront fast, became free and open source. For a store whose main complaint is speed, that removes one of the strongest reasons to leave.

CHANGING RULES

Why Changing a Business Rule Gets Expensive

Imagine a store where the price of a product depends on the country, the cost of delivery depends on the city, and a wholesale client's terms depend on that client's contract. The owner sees three business rules, each of which can be explained in a sentence.

In the software, each rule touches several places at once:

• the catalogue and product variants;
• the price calculation;
• the cart and checkout;
• the integration with the ERP or CRM;
• what the customer sees on the product page and in the order;
• the tests that check every combination of conditions.

In Magento these rules usually end up spread across extensions and modifications of the platform. Its behaviour is defined in XML configuration, dependency injection, plugins and generated classes, so before changing anything a developer first has to find where the final price or delivery cost is actually formed and what else depends on it. That search, and the testing after it, is where a small change becomes a large invoice. In a custom platform the architecture can be organised around the business rules themselves, so each rule has one place where it lives.

The cost of a platform is defined not only by what it can do out of the box, but by how expensive it is to change the business logic when the business changes. This works in Laravel's favour only when the project is designed well: a badly structured Laravel project can become just as hard to change as Magento.

A platform is cheap when changing its rules is cheap.

AI

What AI Changed in Custom Development

For years the case for Magento was simple: writing a store by hand was very expensive, and Magento came with catalogue rules, promotions, taxes and checkout already built. You accepted its complexity because building the same features yourself cost more. What changed that arithmetic is how the work itself is done.

Before AI tools, a change to a store's logic usually went like this:

• a developer studied the structure of the project;
• found the places where the relevant logic was implemented;
• wrote the change;
• checked the related scenarios by hand;
• fixed the side effects that appeared.

With AI tools, the same change goes differently:

• the developer sets the architecture and the constraints;
• an agent explores the codebase and helps find the dependencies;
• it drafts part of the implementation and the tests;
• the developer reviews the code, and the tester checks how the system behaves.

In our team's experience, a good developer and a tester working this way build complex solutions three to five times faster than before, and simpler ones up to ten times faster. That is an observation from our projects, not a universal benchmark. We described how it works on our own system, built in about a month, in CRM vs ERP: What Is the Difference and Which One Do You Need?

AI speeds up writing code. It does not remove the need to design the system, check security, verify calculations and make sure the components work together. In e-commerce this matters more than in most fields: a mistake in a text block is an embarrassment, while a mistake in a price, a tax or a delivery fee costs money on every order until someone notices it. That is why the tester stays in the process, however fast the code is written.

CASE

Case: Lavshash, From Magento to Laravel

Lavshash is a restaurant group with a gastro-market, an online store and restaurant delivery in one system. Product prices and delivery prices differed by region and by city.

Before. The store had been built on Magento by a previous contractor, as a premium and expensive service. At the time many owners believed that the more expensive the CMS, the better the store, and the project started on that basis. In practice every change and every update went through long rounds of approval, then corrections, testing, and corrections again. Critical errors still appeared after releases.

What we changed. We did not start from the code that already existed. We started from the business logic: how prices are formed for each region, how delivery is calculated for each city, how the market, the store and the restaurants share one catalogue. Then we built the platform again on Laravel around those rules. For a system like this it was not a particularly difficult task, and it was done before Claude Code, Codex and Cursor existed.

After. For several years the store ran with minimal support and no serious problems. In the first year alone, the client saved about $17,000 compared with running the Magento store. Over the following years the savings would have been much larger, had the full-scale war not changed the business.

That is not a reason to leave any system unattended: PHP and Laravel versions still need planned upgrades. But it shows how much less a platform can demand just to keep running when it is built around the business.

LARAVEL

Why We Build on Laravel

• The logic stays visible. Laravel's conventions keep business rules in the code where developers expect them. That also matters for AI tools: an agent working on a conventional Laravel project makes fewer mistakes than one working through Magento's layers, and a single AGENTS.md file can describe the whole project.
• The admin panel fits the business. Setting up separate admin views for managers, warehouse staff, wholesale clients or partners, and designing them the way the business needs, is straightforward.
• Large products stay stable. We have built very large products on Laravel, and they did not break and were easy to update. Our own site went from Laravel 7 to 13 in three days, as described in Six Laravel Versions in Three Days; that is one upgrade of one well-kept project, so we treat it as an example and not as a promise for every store.
• There are many Laravel developers. That keeps the project from depending on one specialist and makes support cheaper to hire.

Our Laravel work includes brand projects such as Nicole and Nico Juliany, as well as several brand stores we cannot name. The clearest current example is Schoeffel, a pearl house we are building on Laravel for the long term. It will run in about ten languages, including Chinese and Arabic, and each market has its own taxes, delivery costs, risks and payment commissions, which have to be built into the price of every piece and explained to the customer in advance. We describe that side in Multilingual Website Design: What Changes Beyond Translation. That kind of logic is where building around the business pays off most.

COST OF OWNERSHIP

The Cost of Owning an E-Commerce Platform

Comparing a build quote with a yearly subscription is the most common mistake in this decision. Each option has its own full formula:

A custom platform has no subscription, but it is not free to own. It needs hosting, monitoring, planned upgrades of PHP and Laravel, tests and a team that can maintain it. Those costs belong in the comparison as fully as Shopify's fees.

On Shopify Plus, the public part of the formula is known. The subscription is $2,300 a month on a three-year term or $2,500 on a one-year term, about $138,000 to $150,000 over five years before anything else. A typical app stack adds $12,000 to $60,000 a year. Above roughly $800,000 a month in sales, a variable fee of about 0.35 to 0.40 per cent of revenue applies instead, according to Shopify partners; Shopify does not publish these figures. Cross-border sales add currency conversion fees, and an outside payment gateway adds 0.2 per cent per transaction. A store on Shopify still needs developers and support, and a custom design there is now entirely possible. We build on Shopify too, through our Shopify development service, so this is a comparison we make from both sides.

On Laravel, in our projects a store starts from $25,000, with senior development at $75 an hour. For a simpler store working in one local market we can staff a mid-level developer at $40 to $60 an hour. Support is needed on both platforms; the difference is the subscription, the apps, and who owns the result.

Support is needed on both platforms. Only one of them is yours.

For a standard store with few custom rules, Shopify Plus often comes out cheaper over five years. For a store selling in several markets, with its own pricing, delivery and integrations, the apps, fees and workarounds tend to grow with the business, while the cost of a well-built custom platform grows mainly with new features. That is the calculation we make with a client before recommending anything.

ASSET

What a Buyer Sees

For an owner who may one day sell the business, the platform is also a question of valuation. Valeriya Chumachenko, who works on technology M&A transactions, puts it this way:

"Everything has to be analysed, of course. But most often, your own product on your own hosting, independent of subscriptions and recurring payments, is an asset. SaaS is necessary and sometimes economically justified, but it will not be recorded as a plus for the company in a valuation."

Owning source code does not raise a company's value by itself. A buyer looks at the quality of the technology, the risks, the dependence on key people, the economics of the product and whether it will keep working after the owner changes. Compare two companies that both say they run a custom platform:

• The first owns the code, the documentation, the infrastructure and the data, and several specialists can maintain the system independently.
• The second formally owns the code, but nobody except one developer understands how it works.

For a buyer, these are completely different assets. The first is a controlled technology asset that can be handed over; the second is technical debt and a key-person risk. Checking which of the two a company has is what our technical due diligence session and digital ownership audit are for.

WHEN NOT

When Magento or Shopify Is Still Right

• Stay on Magento if the catalogue is very large, the store runs many store views, B2B relies on Adobe's native features, and there is a strong Magento team in-house. Upgrade to a supported version and consider Hyvä for the storefront.
• Choose Shopify Plus for a standard direct-to-consumer store in one or two markets, with no unusual pricing or delivery rules, run by a team that prefers a managed platform.
• Choose Laravel when pricing, delivery or B2B terms are your own, when you sell in several markets or depend on many integrations, and when owning the platform matters.

MIGRATION

How a Move Off Magento Goes

1. Audit: the extensions in use, the custom code, the integrations and what each of them actually does for the business.

2. Business rules: prices, delivery, taxes and client terms are written down as rules first, because the new platform is built around them.

3. Data: Magento stores products and attributes in a flexible but complex structure, so products, customers and orders are mapped and cleaned before they are moved.

4. Search: every old URL is mapped to its new address with redirects, so the store keeps as much of its search visibility as possible.

5. Parallel run: the new store is tested on real orders while the old one is still available.

6. Cutover: the switch happens at a quiet time, with a rollback plan.

This is the work behind our e-commerce development, and it always starts with the audit rather than the platform choice.

If Shopify Plus looks like the right way out, check the details first: custom logic, payments, fees by order route and URLs. We list eight checks in Moving to Shopify Plus? 8 Things to Check Before You Migrate.

FAQ

Sources

• Adobe Commerce lifecycle policy
• IWD Agency: Adobe Commerce pricing 2026 by revenue band
• Elogic: Shopify Plus pricing 2026
• Amasty: Hyvä theme is now free and open source