Чи йти з 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