Введіть мінімум 3 символи для пошуку

Шість версій Laravel за три дні

Євген Боровой

Founder | CEO

LinkedIn Facebook Instagram Behance

Chapters

    Laravel 7 to 13 upgrade case study: six versions in three days

    Що насправді включає оновлення Laravel, скільки воно коштує в США і чому номер версії рідко буває головною проблемою

    ПРОБЛЕМА

    Сайт працював

    Тримовний корпоративний сайт із власною адмінкою, системою заявок і роками контенту надійно працював на Laravel 7 і PHP 7.4.

    Ніхто не скаржився. Сторінки відкривалися. Форми працювали. Бізнес користувався сайтом щодня.

    Але під поверхнею PHP 7.4 перестав отримувати виправлення безпеки ще в листопаді 2022 року, а Laravel 7 уже багато років не підтримувався.

    Сайт не був зламаний. Він просто старів зсередини.

    Нещодавно ми перевели цей застосунок із Laravel 7 на Laravel 13 і з PHP 7.4 на PHP 8.4. Шість мажорних версій Laravel. Близько трьох днів розробки. Один день приймання. П'ять хвилин запланованого простою. І один закинутий пакет, який виявився важливішим за сам фреймворк.

    Цікаво не те, що ми зробили це швидко. Цікаво зрозуміти, що насправді відбувається під час оновлення Laravel, скільки за це має розраховувати заплатити клієнт у США і чому автоматичний крок за $29 і кошторис на $20 000 можуть існувати одночасно, і жодна з цих цифр не абсурдна.

    Бо єдиної ціни оновлення Laravel не існує. Є лише ціна того, щоб зрозуміти, що саме ви оновлюєте.

    Коротко

    • Laravel не дозволяє пропускати мажорні версії, тож шлях із 7 на 13 це шість окремих міграцій: 8, 9, 10, 11, 12 і 13.
    • Найскладнішим у проєкті був не фреймворк, а закинутий пакет форм, на якому трималося понад 200 полів в адмінці.
    • Дві поломки, які вдарили б по робочому сайту, тиха проблема з поштою і пастка з кешем маршрутів, що перетворила кожну сторінку на 404, були спіймані на закритій тестовій копії.
    • Автоматичні інструменти коштують приблизно від $19 до $39 за крок оновлення. Повне оновлення силами агенції для клієнта в США зазвичай вкладається у $8 000-$25 000. Обидві цифри чесні, просто вони купують різне.
    • Для невеликого і здорового застосунку найдешевшим варіантом може виявитися зробити все самотужки.

    НЕ ОДИН КРОК

    Не одна операція

    Одна з найчастіших помилок уявляти міграцію так: змінити цифру в composer.json, запустити composer update, виправити кілька помилок і піти додому.

    Так це не працює.

    Офіційні посібники Laravel описують кожен мажорний випуск окремо, і фреймворк не підтримує стрибків через проміжні версії. Laravel 13 потребує PHP 8.3 або новішого, а кожна мажорна версія отримує 18 місяців виправлень помилок і два роки виправлень безпеки.

    Тож наш реальний шлях був Laravel 7 → 8 → 9 → 10 → 11 → 12 → 13, і кожен крок ми вели як окрему міграцію. Одна версія. Один коміт. Один цикл перевірки. Потім наступна.

    Звучить як зайва обережність. Це не так. Якщо щось зламалося після шести версій змін, у вас проблема налагодження. Якщо після однієї версії, у вас проблема міграції. Це дуже різні речі.

    І не кожна версія однаково складна, це ще одна причина, чому рахувати версії поганий спосіб оцінювати вартість. Одні випуски спокійні. Інші змінюють компоненти, від яких залежить ваш застосунок. Laravel 9, наприклад, замінив Swift Mailer на Symfony Mailer і перевів роботу з файлами на Flysystem 3. Це не косметика: пошта й файли якраз те, що може виглядати нормально і водночас тихо не працювати. Laravel 11 знову змінив структуру застосунку й конфігурацію. А Laravel 13, за описом самих розробників Laravel, задуманий як порівняно легке оновлення з погляду коду застосунку.

    Тож міграція це не шість однакових робіт. Це шість різних вправ на сумісність. Одні нудні, інші механічні, треті розкривають припущення, зроблені п'ять чи десять років тому. І в одній із них може виявитися те, що робить увесь проєкт дорогим.

    НАШ ВИПАДОК

    Не фреймворк був складнішим

    На папері це був добрий кандидат на оновлення. Жодних складних черг, жодної великої інфраструктури фонових завдань, помірна кількість власного коду. Ризики були в іншому.

    Закинутий пакет форм. Адмінка трималася на бібліотеці форм, яку перестали підтримувати багато років тому, і версії для сучасного Laravel у неї не було. Причому використовувалася вона не раз-два: понад 200 викликів у 29 файлах шаблонів. Замінювати її поле за полем означало перетворити акуратну міграцію на зовсім інший проєкт.

    Файловий менеджер зі своїми маршрутами й налаштуваннями. Робота з файлами якраз та інфраструктура, яка тихо ламається під час оновлення фреймворку.

    Пошта. Найважливіша частина з комерційного погляду. Сайт існує зокрема заради заявок. Якщо перестають відкриватися сторінки, це хтось помітить. Якщо форма показує «дякуємо», а лист так і не приходить, бізнес може виглядати цілком здоровим, поки заявки зникають. Це значно небезпечніше.

    Три мови. Кожна сторінка існує англійською, російською та українською, а мовні префікси беруться з бази даних у момент побудови маршрутів. Пізніше ця деталь виявилася важливою.

    ДО КОДУ

    До першого рядка коду

    Найцінніші години проєкту пішли на те, що було до будь-яких змін.

    Ми створили окрему гілку і записали точний коміт робочого сайту. Підняли закриту тестову копію з базою і файлами, закриту на рівні сервера, а не просто позначену noindex. Записали розширення PHP, налаштування, команди викатки й порядок відкату. І лише потім почали.

    Робочий сайт увесь цей час ніхто не чіпав.

    Звучить очевидно. Але це не так. Напрочуд багато міграцій старих систем стають дорогими через те, що хтось починає змінювати робочий сайт, ще не розуміючи до кінця, з чим має справу.

    Робочий сайт не лабораторія. Це те, що приносить гроші.

    ШІСТЬ ВЕРСІЙ

    По одній версії

    • Laravel 8: спокійний крок. Зміни в структурі й налаштуваннях, нічого драматичного.
    • Laravel 9: перший по-справжньому цікавий крок. Нова поштова бібліотека і новий шар роботи з файлами: саме ті місця, де сайт і далі нормально відображається, поки щось під капотом уже перестало працювати.
    • Пакет форм: замість того щоб замінювати двісті полів по одному, розробник написав невелику прослойку сумісності, яка зберегла те, як адмінка вже викликала свої форми. Один із головних ризиків проєкту пішов без переписування адмінки.
    • Laravel 10: файловий менеджер оновили й захистили, а застарілу назву часового поясу замінили. Дрібниця, але з тих, що непомітно лежать до переходу на нову версію середовища.
    • Laravel 11: ще один важливий крок для налаштувань пошти. Саме тут перевірка спіймала те, що на робочому сайті було б особливо неприємно.
    • Laravel 12 і 13: на цей момент сам фреймворк ставав дедалі менш цікавим. Решта роботи була порівняно спокійною. Потім настала черга PHP 8.4.

    Після кожного кроку ми перевіряли публічний сайт, адмінку, форми й журнал помилок. Мета була не довести, що Laravel оновився. Мета була довести, що бізнес пережив оновлення.

    НА МЕЖІ

    Що мало не зламалося

    Дві речі створили б реальні проблеми. Обидві спіймано на тестовій копії. Жодна не обов'язково була б помітна відвідувачеві.

    Лист, якого більше немає. У Laravel 11 змінився спосіб налаштування шифрування пошти. Зі старими налаштуваннями сайт виглядав би нормально. Форма відправилася б, відвідувач побачив би звичайне повідомлення про успіх, і ніщо на екрані не сказало б: ваша заявка щойно зникла. Ми надіслали справжню тестову заявку й дочекалися листа. Лише після цього крок вважався завершеним. У цьому і різниця між «код працює» і «бізнес працює».

    Оптимізація, яка перетворила кожну сторінку на 404. Laravel уміє кешувати маршрути для швидкості, і зазвичай це цілком розумна оптимізація. На цьому сайті вона виявилася помилкою. Мовні префікси бралися з бази в момент побудови маршрутів, і кеш «заморозив» маршрути без інформації про мову. Кожна сторінка копії одразу почала відповідати «не знайдено». Скасувати це забрало близько хвилини. На робочому сайті це була б аварія.

    Тож тепер у нас є дуже конкретне правило проєкту: на цьому проєкті маршрути не кешувати ніколи. І це правило живе не лише в чиїйсь пам'яті. Воно записане в інструкціях проєкту для розробників і ШІ-агентів, у тому самому файлі, про який ми писали у статті «Вашому коду потрібна інструкція для ШІ». Агенту не треба знати всі можливі оптимізації Laravel. Йому треба знати реальність цього проєкту.

    І третя, дрібніша: у початковому плані відкату точкою повернення був тег версії, поставлений до кількох днів іншої роботи. Відкат на нього тихо знищив би і її. Точку відкату замінили на точний коміт робочого сайту.

    ВИКАТКА

    Викатка і тихі поломки

    Оскільки всю складну роботу зроблено заздалегідь, сама викатка вийшла короткою й нудною, а саме такою викатка і має бути. Резервна копія, злиття, встановлення нових залежностей під PHP 8.4, перемикання версії PHP у панелі хостингу, очищення кешів. Єдиний реальний простій це час, за який хостинг застосував нову версію PHP: близько п'яти хвилин, у запланований тихий час.

    А потім почалося те, що справді важливо.

    Сайт, який видає фатальну помилку, видно одразу. Сайт, який виглядає нормально і водночас втрачає заявки, ні. Тому наше приймання це не просто «застосунок відкривається?». Для цієї міграції ми перевірили 15 публічних сторінок трьома мовами, 30 екранів адмінки, справжню тестову заявку з підтвердженим листом, журнал помилок і 987 внутрішніх посилань.

    Нуль битих посилань. Ось що насправді означає «оновлення працює».

    ШВИДКІСТЬ

    А ще швидкість

    Одна з найкорисніших знахідок узагалі не стосувалася фреймворку.

    Готуючись до викатки, ми заміряли старий сайт і помітили, що в тарифі хостингу є OPcache, кеш скомпільованого PHP-коду, і його ніколи не вмикали. Без нього PHP заново компілює кожен файл на кожному запиті. Щойно ми його ввімкнули, старий сайт на Laravel 7 почав відповідати на сервері приблизно за 21 мілісекунду замість 55. Приблизно у два з половиною рази швидше, за кілька доларів на місяць.

    Після оновлення, з увімкненим OPcache, Laravel 13 відповідав приблизно за 25 мілісекунд. Новий фреймворк завантажує більше коду, і швидший PHP приблизно це компенсує.

    Тож Laravel 13 не зробив сайт чарівним чином швидшим. Це зробило налаштування, яке роками просто лежало без діла. Не редизайн. Не переробка. Не новий застосунок.

    Іноді найбільше покращення зовсім не те, за що ви думали, що платите. Це ще одна причина починати оновлення з аудиту, а не з кошторису.

    ВАРТІСТЬ

    Скільки це коштує

    Тут проста відповідь починає вводити в оману. Пошукайте ціни на оновлення Laravel, і ви знайдете все: від кількох десятків доларів до десятків тисяч. І всі ці цифри можуть бути чесними. Просто вони платять за різне.

    Laravel Shift, найвідоміший сервіс автоматизації, бере приблизно від $19 до $39 за крок оновлення залежно від версії, а підписка починається від $99 на рік за репозиторій. За власною оцінкою Shift, його перехід на Laravel 12 заощаджує близько двох годин роботи, а на Laravel 13 близько однієї.

    Це не міграція Laravel за $29. Це автоматичний крок за $29. Це дуже різні речі.

    Для клієнта в США у 2026 році корисніше думати про оновлення Laravel рівнями. Один із посібників щодо цін на Laravel наводить ставки розробників у США та Західній Європі на рівні $100-$200 за годину, а у Східній Європі $35-$75. Лише цей розкид пояснює багато що в кошторисах.

    1. Зробити самотужки: від $30 до $500+. Shift чи Rector, ШІ-агент для програмування, тестовий сервер, ваш час і вихідні. Для невеликого застосунку на Laravel із добрими тестами, без закинутих залежностей і з невеликою кількістю власної бізнес-логіки платити комусь кілька тисяч доларів лише тому, що версія фреймворку стара, може бути економічно безглуздо. Проблема не в інструменті. Проблема в тому, щоб знати, чи справді ваш застосунок такий простий.

    2. Автоматизація плюс перевірка розробником: приблизно $1 000-$5 000. Автоматика робить механічні зміни, а людина, яка знає Laravel, перевіряє кожен крок, проганяє тести й дивиться залежності на тестовій копії. Для порівняно здорового застосунку це працює дуже добре. Деякі опубліковані ціни перебувають у нижній частині цього рівня: один фахівець оцінює оновлення на одну версію в доглянутому застосунку в один-три дні, а відставання на три й більше версій без тестів і з закинутими пакетами у три-шість тижнів, від $2 500. Автоматизація дешева. Дорога тут людина, яка розуміє, коли автоматика помиляється.

    3. Фрилансер: приблизно $3 000-$10 000. Для невеликих і середніх застосунків тямущий незалежний розробник на Laravel часто найекономніший платний варіант. Ціна сильно залежить від стану застосунку: на один проєкт фрилансер може витратити 20 годин, а на інший, майже такий самий ззовні, 100.

    4. Професійне оновлення за фіксованою ціною: приблизно $8 000-$25 000. Тут опубліковані ціни саме на оновлення Laravel стають корисними. Один із прикладів це постачальник з Індії, який продає оновлення за фіксованою ціною клієнтам зі США та Великої Британії: платна оцінка за $750-$1 500, далі від $8 000 за невеликі застосунки з одним-двома кроками до $25 000 за великі застосунки з п'ятьма й більше кроками чи платежами. Якщо офшорний постачальник оцінює роботу так, американська агенція зі своїми ставками зазвичай буде на цьому рівні або вище. Клієнт платить не за «Laravel 7 → 13». Він платить за вивчення, аналіз залежностей, тестову копію, міграцію по одній версії, перевірку, викатку, план відкату і за те, що хтось відповідає, якщо щось піде не так.

    5. Складний застосунок: $25 000-$50 000+. Платежі, кілька зовнішніх API, мультиорендність, черги, власна авторизація, великі адмінки, закинуті пакети, відсутність тестів. Тут ви вже робите не міграцію фреймворку, а модернізацію застосунку. Навіть за офшорними ставками один аналіз 2026 року оцінює середній SaaS із відставанням на три-чотири версії у $14 000-$30 000, а великий корпоративний застосунок у $25 000-$70 000 і більше.

    6. Корпоративна модернізація: $50 000+. У масштабі великої компанії Laravel майже другорядний. CRM, ERP, платежі, єдиний вхід, потоки даних, вимоги регуляторів, кілька команд. Міграція стає програмою, а не оновленням, і вартість визначають координація, перевірка й безперервність бізнесу.

    Це орієнтири для планування, а не універсальні ринкові ціни, і реальна сума залежить від стану коду. Але вони пояснюють позірну суперечність: автоматичний крок за $29 і проєкт за $20 000 не конкурентні продукти. Один купує автоматизацію. Інший купує контрольований результат.

    ТРИ ДНІ

    Три дні це не ціна

    Мабуть, це головний урок нашого випадку. Хтось прочитає «Laravel 7 → 13, три дні» і вирішить: тоді чому мені виставляють $15 000?

    Бо три дні це час реалізації саме цієї міграції після того, як на складні питання вже було отримано відповіді. Проєкт вимагав ще зрозуміти наявний застосунок, знайти закинутий пакет, вирішити не переписувати 200 полів форм, зробити прослойку сумісності, підняти тестову копію, спланувати відкат, перевірити пошту, три мови й адмінку, перевірити поведінку маршрутів, перевірити 987 внутрішніх посилань, підготувати викатку і провести приймання.

    Сама викатка зайняла хвилини. Це не означає, що проєкт зайняв хвилини. Це означає, що підготовка спрацювала. І саме за це ви платите, коли наймаєте досвідчених людей.

    МНОЖНИК

    Занедбаність, а не версії

    Якби це був друкований журнал, цей рядок я б виділив жирним: вартість міграції визначається радше накопиченою занедбаністю, ніж відстанню між версіями.

    Застосунок на Laravel 10 → 13 може виявитися складнішим, ніж на Laravel 7 → 13. Застосунок на Laravel 10 може не мати тестів, зате мати шість закинутих пакетів, власний форк, недокументовану інтеграцію з платежами, дивний процес викатки і трьох розробників, які пішли з компанії. А застосунок на Laravel 7 може виявитися напрочуд чистим.

    Номер версії каже, де ви перебуваєте. Він не каже, що чекає під поверхнею.

    Вартість міграції визначає занедбаність, а не відстань між версіями.

    ОЧІКУВАННЯ

    Чому чекати дорого

    З кожним роком очікування ви додаєте не просто ще один номер версії. Ви накопичуєте припущення. Залежності старіють. Розробники йдуть. Хостинг змінюється. Зовнішні API змінюються. Пакети зникають. І в якийсь момент людини, яка знала, чому все влаштовано саме так, поруч уже немає.

    Одна агенція описує клієнта, чиє оновлення коштувало б $8 000, а через вісім місяців, під тиском термінів і з новими інтеграціями на застарілих пакетах, обійшлося в $26 000. Laravel робить цей цикл явним: підтримка безпеки Laravel 11 закінчилася 12 березня 2026 року, Laravel 12 отримує виправлення безпеки до 24 лютого 2027 року, а Laravel 13 до 17 березня 2028 року.

    Найдешевша міграція зазвичай та, яку не довели до стану археології.

    ШІ

    Що змінює ШІ

    Є ще одна велика відмінність 2026 року від 2021-го. Тепер у нас є агенти для програмування: Claude Code, Codex, Cursor, а поруч інструменти на кшталт Rector і Laravel Shift. Агент може прочитати код, знайти застарілі API, оновити однотипний синтаксис, пояснити зміни, запустити тести й виправити прості падіння. Це змінює економіку механічної частини.

    Але не змінює головний ризик. Агент може домогтися, щоб код компілювався і наявні тести проходили. Він не може сам знати, що форма, яка показує «дякуємо», але більше не надсилає лист, це провал для бізнесу.

    ШІ може пришвидшити міграцію. Відповідати за неї він не може.

    САМОТУЖКИ

    Спершу спробуйте самі

    Хочемо сказати це прямо, бо це чесно.

    Якщо у вас невеликий застосунок на Laravel, тямущий розробник у команді, тестове середовище і добра стратегія резервного копіювання: спершу спробуйте дешеві варіанти. Використайте Shift. Використайте Rector. Використайте ШІ-агента. Прочитайте офіційні посібники з оновлення. Рухайтеся по одній версії. Перевіряйте все, особливо те, що не видає помилок, коли ламається.

    Можливо, агенція вам не потрібна.

    Ми не вважаємо, що кожен старий застосунок на Laravel має перетворюватися на консалтинговий проєкт за $15 000. Один має коштувати $500. Інший $5 000. Третій $25 000. А якийсь краще переробити з нуля. Єдиний спосіб дізнатися, який у вас, це зазирнути в застосунок.

    РІШЕННЯ

    Оновлювати, переробляти чи чекати?

    Насправді рішень три.

    • Оновлювати, якщо бізнес-логіка здорова, застосунок варто зберегти, а головна проблема в технічному віці.
    • Переробляти, якщо модернізація однаково починає вимагати заміни більшої частини застосунку. Поширене галузеве правило: порівнювати велике оновлення з чистою переробкою, коли оцінка оновлення наближається приблизно до 60% вартості переробки. Це не закон, але корисна точка, щоб перестати вважати, що «оновити» автоматично дешевше.
    • Чекати, лише якщо застосунок справді незабаром замінять. Інакше очікування не безкоштовне: ви перетворюєте сьогоднішній керований проєкт на завтрашню аварію.

    УРОК

    Найпростіша частина

    Озираючись назад, саме оновлення фреймворку було найпередбачуванішою частиною проєкту. Цінність була в усьому навколо нього: знайти закинутий пакет до того, як він став аварією, зрозуміти, яку проблему сумісності розв'язати, а не переписувати, спіймати тиху поломку пошти й пастку з кешем маршрутів, записати точний коміт робочого сайту, перевіряти на закритій копії, точно знати, як відкотитися.

    І зрештою записати уроки проєкту в його власні інструкції.

    Ця остання частина стає дедалі важливішою. Наступного разу, коли ШІ-агент увійде в цей код, йому не доведеться заново відкривати той самий урок. Він уже знає: тут маршрути не кешувати. Зовсім маленька інструкція. Але за нею стоїть щось значно більше.

    Проєкт почав пам'ятати.

    І, можливо, у цьому і є справжня мета модернізації. Не просто перейти з Laravel 7 на Laravel 13 чи з PHP 7.4 на PHP 8.4, а перетворити систему, яка роками накопичувала невидимі рішення, на систему, яку наступний розробник, людина чи ШІ, справді зможе зрозуміти.

    Тому питання ніколи не звучить просто як «Скільки коштує оновлення Laravel?» Правильне питання: «Наскільки треба зрозуміти саме цей код, перш ніж його змінювати?» Бо насправді ви платите саме за це.

    Якщо хочете спершу побачити ширшу картину, наш посібник про оновлення старого сайту на Laravel чи PHP розбирає рішення крок за кроком. А якщо хочете другу думку щодо свого застосунку, наша робота з модернізації сайтів починається з аудиту, який покаже, який варіант вам підходить, зокрема ті, де ми вам не потрібні.

    FAQ

    Питання та відповіді

    Скільки коштує оновлення Laravel у США?

    Від десятків доларів за автоматичні кроки, які ви запускаєте самі, до $8 000-$25 000 за професійне оновлення за фіксованою ціною і $25 000-$50 000 і більше для складних застосунків. Стан коду важливіший за кількість версій.

    Скільки триває оновлення з Laravel 7 на 13?

    У нашому випадку близько трьох днів розробки, один день приймання і п'ять хвилин простою. Застосунки з великою кількістю власного коду, інтеграціями чи без тестів можуть займати кілька тижнів.

    Чи можна пропускати версії Laravel?

    Ні. Laravel оновлюється по одній мажорній версії за раз, і PHP зазвичай доводиться оновлювати разом із ним. Laravel 13 потребує PHP 8.3 або новішого.

    Чи достатньо Laravel Shift?

    Він автоматизує значну частину механічної роботи приблизно за $19-$39 за крок і добре підходить, якщо хтось може перевіряти й тестувати кожен крок. Він не перевіряє ваші форми, доставку пошти, інтеграції та індексацію.

    Чи стане сайт швидшим після оновлення?

    Саме по собі ні. Нові версії Laravel завантажують більше коду. У нашому випадку реальний приріст швидкості дав увімкнений на хостингу OPcache.

    Джерела

    Ваш застосунок працює на старому Laravel чи PHP? Дізнайтеся, що йому насправді потрібно, перш ніж вам назвуть ціну.

    Модернізація сайтів

    Підтримка і супровід сайтів

    Записатися на стратегічну сесію