Уходить ли с Magento в 2026 году: обновление, Shopify Plus или Laravel?

За годы работы с магазинами, которые переросли Magento, мы стали гораздо осторожнее рекомендовать новую установку Magento. Рассказываем, как сравниваем три варианта и почему для многих магазинов ответом оказывается Laravel.

КОРОТКИЙ ОТВЕТ

Уходить ли с Magento: короткий ответ

У магазина на устаревшей версии Magento есть три реальных варианта: обновить Magento, перейти на Shopify Plus или перейти на собственную платформу на Laravel. Для стандартного магазина, который продаёт напрямую покупателям на одном-двух рынках, Shopify Plus часто оказывается самым простым выбором. Для очень большого каталога с множеством витрин и встроенными B2B-функциями Adobe остаться на Magento может быть оправданно. Магазинам со своей логикой цен и доставки, несколькими рынками или большим числом интеграций мы чаще рекомендуем Laravel.

Самый сильный аргумент в пользу Laravel состоит в том, что систему можно построить вокруг процессов конкретного бизнеса и потом контролировать, сколько стоит её менять. Отсутствие лицензии помогает, AI делает собственную разработку доступнее, а владение кодом даёт больше контроля, но ни один из этих факторов по отдельности не гарантирует низкую стоимость владения. Решает то, как они работают вместе в ближайшие пять лет.

СРОКИ

Сроки, от которых зависит решение

Для многих магазинов вопрос стал срочным из-за графика поддержки Adobe. Стандартная поддержка Magento 2.4.6 закончилась 11 августа 2026 года. Для 2.4.7 она заканчивается 31 мая 2027 года. Новые версии 2.4.8 и 2.4.9 поддерживаются до 2028 и 2029 года, так что Magento как платформа никуда не исчезает; заканчивается поддержка той версии, на которой работает конкретный магазин. Поэтому любому магазину на старой версии в любом случае предстоит проект: обновление или переезд.

Есть и честный аргумент в пользу того, чтобы остаться. В ноябре 2025 года тема Hyvä, самый популярный способ сделать витрину Magento быстрой, стала бесплатной и открытой. Если главная претензия к магазину в скорости, одна из самых веских причин уходить отпадает.

БИЗНЕС-ПРАВИЛА

Почему изменение бизнес-правила обходится дорого

Представьте магазин, где цена товара зависит от страны, стоимость доставки зависит от города, а условия для оптового клиента зависят от его договора. Владелец видит три бизнес-правила, и каждое можно объяснить одной фразой.

В программе каждое из них затрагивает сразу несколько мест:

• каталог и варианты товаров;
• расчёт цены;
• корзину и оформление заказа;
• интеграцию с ERP или CRM;
• то, что покупатель видит на странице товара и в заказе;
• тесты, которые проверяют все сочетания условий.

В Magento такие правила обычно оказываются разбросаны по расширениям и доработкам платформы. Её поведение задаётся в XML-конфигурации, через dependency injection, плагины и сгенерированные классы, поэтому прежде чем что-то менять, разработчику нужно найти, где на самом деле формируется итоговая цена или стоимость доставки и что ещё от этого зависит. Именно на этих поисках и последующем тестировании небольшое изменение превращается в большой счёт. В собственной платформе архитектуру можно выстроить вокруг самих бизнес-правил, чтобы у каждого правила было одно место, где оно живёт.

Стоимость платформы определяется не только тем, что она умеет из коробки, но и тем, насколько дорого обходится изменение бизнес-логики, когда меняется бизнес. Это работает в пользу Laravel только при хорошем проектировании: плохо выстроенный проект на Laravel может стать таким же сложным для изменений, как Magento.

Платформа дешёвая, когда дёшево менять её правила.

AI

Что AI изменил в собственной разработке

Долгие годы аргумент в пользу Magento был простым: писать магазин с нуля было очень дорого, а в Magento уже были правила каталога, акции, налоги и оформление заказа. Его сложность принимали, потому что построить то же самое самостоятельно стоило дороже. Эту арифметику изменил сам способ работы.

До AI-инструментов изменение логики магазина обычно выглядело так:

• разработчик изучал структуру проекта;
• искал места, где реализована нужная логика;
• писал изменение;
• вручную проверял связанные сценарии;
• исправлял побочные эффекты, которые всплывали после.

С AI-инструментами то же изменение проходит иначе:

• разработчик задаёт архитектуру и ограничения;
• агент исследует кодовую базу и помогает найти зависимости;
• он готовит часть реализации и тестов;
• разработчик проверяет код, а тестировщик проверяет, как ведёт себя система.

По опыту нашей команды, хороший разработчик и тестировщик, работая так, создают сложные решения в три-пять раз быстрее, чем раньше, а более простые до десяти раз быстрее. Это наблюдение из наших проектов, а не универсальный показатель. Как это работает на нашей собственной системе, построенной примерно за месяц, мы рассказали в статье о разнице между CRM и ERP.

AI ускоряет написание кода. Он не отменяет необходимости проектировать систему, проверять безопасность, правильность расчётов и совместную работу компонентов. В e-commerce это важнее, чем в большинстве других областей: ошибка в тексте на странице просто неприятна, а ошибка в цене, налоге или стоимости доставки стоит денег на каждом заказе, пока её кто-нибудь не заметит. Поэтому тестировщик остаётся в процессе, как бы быстро ни писался код.

КЕЙС

Кейс Lavshash: переход с Magento на Laravel

Lavshash объединяет ресторанную группу, гастромаркет, интернет-магазин и доставку из ресторанов в одной системе. Цены на товары и на доставку различались по регионам и городам.

До. Магазин на Magento делал предыдущий подрядчик, как премиальную и дорогую услугу. В то время многие владельцы считали, что чем дороже CMS, тем лучше магазин, и проект стартовал именно с этой логики. На практике каждое изменение и каждое обновление проходило долгие этапы согласования, затем правки, тестирование и снова правки. После релизов всё равно всплывали критические ошибки.

Что мы изменили. Мы не отталкивались от уже написанного кода. Мы начали с бизнес-логики: как формируются цены для каждого региона, как рассчитывается доставка для каждого города, как маркет, магазин и рестораны делят один каталог. Затем построили платформу заново на Laravel вокруг этих правил. Для такой системы это была не очень сложная задача, и сделали мы её ещё до появления Claude Code, Codex и Cursor.

После. Несколько лет магазин работал с минимальной поддержкой и без серьёзных проблем. Только за первый год клиент сэкономил около $17 000 по сравнению с содержанием магазина на Magento. В следующие годы экономия была бы намного больше, если бы полномасштабная война не изменила бизнес.

Это не повод оставлять любую систему без присмотра: версии PHP и Laravel всё равно нужно обновлять по плану. Но пример показывает, насколько меньше требует платформа просто для того, чтобы работать, когда она построена вокруг бизнеса.

LARAVEL

Почему мы строим на Laravel

• Логика остаётся на виду. Соглашения Laravel держат бизнес-правила в коде там, где разработчик ожидает их найти. Это важно и для AI-инструментов: агент в стандартном Laravel-проекте ошибается реже, чем в слоях Magento, а один файл AGENTS.md может описать весь проект.
• Админка подстраивается под бизнес. Настроить отдельные разделы для менеджеров, склада, оптовых клиентов или партнёров и оформить их так, как нужно бизнесу, несложно.
• Большие продукты остаются стабильными. Мы строили на Laravel очень большие продукты, и они не ломались и легко обновлялись. Наш собственный сайт перешёл с Laravel 7 на 13 за три дня, об этом мы писали в статье о шести версиях Laravel за три дня; это одно обновление одного аккуратно поддерживаемого проекта, поэтому мы считаем его примером, а не обещанием для любого магазина.
• Разработчиков на Laravel много. Проект не зависит от одного специалиста, а поддержку дешевле найти.

Среди наших проектов на Laravel есть бренды Nicole и Nico Juliany, а также несколько брендовых магазинов, которые мы не можем назвать. Самый наглядный пример сейчас в работе: Schoeffel, жемчужный дом, который мы строим на Laravel на долгие годы. Сайт будет работать примерно на десяти языках, включая китайский и арабский, и у каждого рынка свои налоги, стоимость доставки, риски и платёжные комиссии, которые нужно заложить в цену каждого изделия и заранее объяснить покупателю. Об этой стороне мы рассказали в статье о дизайне мультиязычного сайта. Именно в такой логике построение вокруг бизнеса окупается сильнее всего.

СТОИМОСТЬ ВЛАДЕНИЯ

Сколько стоит владеть платформой интернет-магазина

Самая частая ошибка в этом решении состоит в том, чтобы сравнивать смету на разработку с годовой подпиской. У каждого варианта своя полная формула:

У собственной платформы нет подписки, но владение ею не бесплатно. Ей нужны хостинг, мониторинг, плановые обновления PHP и Laravel, тесты и команда, способная её поддерживать. Эти расходы должны войти в сравнение так же полно, как платежи Shopify.

У Shopify Plus публичная часть формулы известна. Подписка стоит $2300 в месяц при контракте на три года или $2500 при контракте на год, то есть примерно от $138 000 до $150 000 за пять лет, ещё до всех остальных расходов. Типичный набор приложений добавляет от $12 000 до $60 000 в год. При продажах примерно от $800 000 в месяц вместо этого действует плата около 0,35-0,40% от оборота, по данным партнёров Shopify; сама Shopify эти цифры не публикует. Продажи в другие страны добавляют комиссии за конвертацию валют, а сторонний платёжный шлюз добавляет 0,2% с каждой транзакции. Магазину на Shopify всё равно нужны разработчики и поддержка, а собственный дизайн там сегодня вполне возможен. Мы и сами работаем с Shopify в рамках услуги разработки на Shopify, поэтому сравниваем с обеих сторон.

На Laravel магазин в наших проектах стоит от $25 000, час сеньор-разработчика $75. Для более простого магазина, работающего на одном локальном рынке, мы можем подключить мидл-разработчика по $40-60 в час. Поддержка нужна на обеих платформах; разница в подписке, приложениях и в том, кому принадлежит результат.

Поддержка нужна на обеих платформах. Ваша только одна из них.

Для стандартного магазина с небольшим количеством своих правил Shopify Plus за пять лет часто выходит дешевле. Для магазина, который продаёт на нескольких рынках, со своей логикой цен, доставки и интеграциями, приложения, комиссии и обходные решения обычно растут вместе с бизнесом, а стоимость хорошо построенной собственной платформы растёт в основном с новыми функциями. Именно этот расчёт мы делаем вместе с клиентом, прежде чем что-то рекомендовать.

АКТИВ

Что видит покупатель бизнеса

Для владельца, который однажды может продать бизнес, платформа становится ещё и вопросом оценки. Валерия Чумаченко, которая работает на сделках M&A в сфере технологий, формулирует это так:

«Конечно, всё нужно анализировать. Но чаще всего собственный продукт на собственном хостинге, не зависящий от подписок и регулярных платежей, является активом. SaaS необходим и иногда экономически оправдан, но при оценке он не будет записан компании в плюс».

Владение исходным кодом само по себе не повышает стоимость компании. Покупатель смотрит на качество технологии, риски, зависимость от ключевых людей, экономику продукта и на то, продолжит ли система работать после смены владельца. Сравните две компании, которые обе говорят, что у них собственная платформа:

• Первая владеет кодом, документацией, инфраструктурой и данными, и несколько специалистов могут независимо поддерживать систему.
• Вторая формально владеет кодом, но никто, кроме одного разработчика, не понимает, как он работает.

Для покупателя это совершенно разные активы. Первая компания владеет контролируемым технологическим активом, который можно передать; у второй технический долг и риск зависимости от одного человека. Проверить, какой из двух вариантов у компании, помогают наши сессия технического due diligence и аудит цифровой собственности.

КОГДА НЕТ

Когда Magento или Shopify всё ещё правильный выбор

• Оставайтесь на Magento, если каталог очень большой, у магазина много витрин, B2B держится на встроенных функциях Adobe, а в компании есть сильная команда по Magento. Обновитесь до поддерживаемой версии и рассмотрите Hyvä для витрины.
• Выбирайте Shopify Plus для стандартного магазина с продажами напрямую покупателям на одном-двух рынках, без нестандартных правил цен и доставки, если команда предпочитает управляемую платформу.
• Выбирайте Laravel, когда правила цен, доставки или B2B-условия у вас свои, когда вы продаёте на нескольких рынках или зависите от многих интеграций и когда для вас важно владеть платформой.

ПЕРЕЕЗД

Как проходит переезд с Magento

1. Аудит: какие расширения используются, какой написан собственный код, какие есть интеграции и что каждая из них на самом деле даёт бизнесу.

2. Бизнес-правила: цены, доставка, налоги и условия для клиентов сначала записываются как правила, потому что новая платформа строится вокруг них.

3. Данные: Magento хранит товары и атрибуты в гибкой, но сложной структуре, поэтому товары, клиенты и заказы сопоставляются и очищаются до переноса.

4. Поиск: каждый старый URL получает новый адрес с редиректом, чтобы магазин сохранил как можно больше видимости в поиске.

5. Параллельная работа: новый магазин проверяется на реальных заказах, пока старый ещё доступен.

6. Переключение: проходит в спокойное время, с планом отката.

Это и есть работа, которая стоит за нашей разработкой интернет-магазинов, и она всегда начинается с аудита, а не с выбора платформы.

Если выходом кажется Shopify Plus, сначала проверьте детали: свою логику, платежи, комиссии по маршрутам заказов и URL. Восемь проверок мы собрали в статье «Переходите на Shopify Plus? 8 вещей, которые стоит проверить до миграции».

FAQ

Источники

• 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