Оновлення старого сайту на Laravel чи PHP у 2026 році

Реальні витрати, реальні інструменти і питання, яке ніхто не ставить першим

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

Саме в цьому небезпека.

На головній не з'являється напис: ЦЕЙ САЙТ ПРАЦЮЄ НА ПРОГРАМАХ 2018 РОКУ. Нічого не червоніє, коли у фреймворку закінчується підтримка. Ніхто не отримує сповіщення, що пакет, на якому тримається пів адмінки, давно закинутий. Сайт може виглядати цілком здоровим, поки технології під ним дедалі важче підтримувати, захищати і змінювати.

Власники рідко бувають безтурботними. Зазвичай сайт просто жодного разу не дав їм приводу зазирнути всередину.

Тому справжнє питання 2026 року не в тому, чи відкривається старий сайт на Laravel або PHP. Звісно, відкривається. Питання в тому, яка частина бізнесу сьогодні залежить від програм, на які роками ніхто уважно не дивився.

Коротко

• Понад третина PHP-сайтів досі працює на PHP 7 або PHP 5, які більше не отримують виправлень безпеки (W3Techs, вересень 2026).
• Laravel оновлюється лише по одній мажорній версії за раз, і PHP має оновлюватися разом із ним: Laravel 13 потребує PHP 8.3 або новішого.
• Автоматичні інструменти беруть на себе механічні кроки, але основні витрати йдуть на тестування, закинуті пакети й тихі поломки на кшталт недоставлених листів.
• Чесну ціну оновлення старого сайту можна назвати лише після аудиту; про переробку з нуля варто говорити, коли оновлення наближається до 60% її вартості.
• Оновлення часто розкриває проблеми поза кодом, наприклад хостинг, що закриває сайт від ШІ-роботів, і вони заслуговують не меншої уваги.

ІЛЮЗІЯ

Сайт, що виглядав нормально

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

Нещодавно ми дивилися сайт, власник якого не мав видимих причин для хвилювання. Сторінки працювали. Бізнес користувався сайтом щодня. А під капотом сервер працював на PHP 5.6. Хостинг-акаунт контролювала стороння людина. Службові скрипти лежали у відкритому доступі, відвідувачі могли бачити помилки PHP, а листи з форми заявок поштовий сервер мовчки відхиляв.

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

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

Виправлення тоді не потребувало героїчної переробки. Це був акуратний переїзд на хостинг, який контролює власник, оновлення до PHP 8.2, закриття відкритих шляхів і відновлення доставки пошти. Робота зайняла два вечори.

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

ВІЗУАЛЬНИЙ ВІК

Молодий зовні, старий усередині

Ця різниця напрочуд часто губиться.

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

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

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

ЦИФРИ

Наскільки далеко ви відстали?

PHP і далі працює на більшій частині інтернету. За даними W3Techs на вересень 2026 року, його використовують 70,2% сайтів з відомою серверною мовою. Але картина за версіями нерівна: 63,4% PHP-сайтів працюють на PHP 8, а 28,7% досі на PHP 7 і 7,9% на PHP 5.

PHP 7 і PHP 5 більше не отримують виправлень безпеки. Але й PHP 8 сам по собі нічого не гарантує, бо кожна гілка має свій строк підтримки:

• PHP 7.4: виправлення безпеки закінчилися 28 листопада 2022
• PHP 8.1: закінчилися 31 грудня 2025
• PHP 8.2: до 31 грудня 2026
• PHP 8.3: до 31 грудня 2027
• PHP 8.4: до 31 грудня 2028
• PHP 8.5: до 31 грудня 2029

Laravel живе за ще коротшим циклом. Кожна версія отримує 18 місяців виправлень помилок і два роки виправлень безпеки. З весни 2026 року підтримуються лише Laravel 12 і 13, а Laravel 11 втратив підтримку безпеки 12 березня 2026 року.

Ці дати цікаві не тому, що цікаві номери версій. Вони важливі тому, що разом із ними рухається вся екосистема.

ДОРОГА

Дорога не чекатиме

Компанія може вирішити залишитися на старій платформі ще на рік. Технічно це можливо. Змінюється все навколо.

І більша частина ринку вже вирішила рухатися. У звіті Zend 2026 PHP Landscape Report 68% команд на PHP завершили перехід за останні 12 місяців, а у 67% він запланований на найближчі 12 місяців. Нічого не планують лише 21%.

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

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

Тому ціна застарілої системи це не лише ціна виправлення старого фреймворку. Це зростаюча ціна того, що ви стаєте винятком, і про це ми писали у статті про приховану ціну стояння на місці.

КІНЕЦЬ ПІДТРИМКИ

Коли підтримка закінчується

Зазвичай у сам день завершення підтримки нічого драматичного не стається. Тому цю дату так легко пропустити. Ризик зростає тихо:

• Безпека. Вразливості продовжують знаходити, але виправлення для версії без підтримки вже не виходять.
• Хостинг. Рано чи пізно хостинг вимикає старі версії PHP, і іноді переїжджати доводиться під тиском.
• Інтеграції. Нові платіжні модулі, конектори CRM і плагіни відмовляються встановлюватися на стару платформу.
• Люди. Дедалі менше розробників хочуть брати системи без підтримки, а ті, хто бере, закладають ризик у ціну.

Темп із боку безпеки варто знати. Patchstack нарахував 11 334 нові вразливості в екосистемі WordPress за 2025 рік, при цьому медіанний час до першої експлуатації найбільш атакованих вразливостей близько п'яти годин. Не кожен PHP-сайт у тій самій зоні ризику. Але це показує, як швидко змінюється середовище, поки система без підтримки стоїть на місці.

ШІ ТА ІНТЕГРАЦІЇ

Не лише безпека

Безпека важлива. Але рідко саме вона змушує власника бізнесу діяти. Зазвичай приводом стає те, що він хоче побудувати далі.

ШІ-асистент. Пошук, який розуміє запитання, а не точні фрази. CRM, яка спілкується із сайтом. Нова платіжна система. Особистий кабінет клієнта. Інтеграція, яку стара система не витягує.

Це змінює розмову. Якщо клієнт просить додати ШІ-асистента, а аудит знаходить Laravel 7, питання вже не просто «чи оновлюватися?». Корисніше спитати: «Що ми хочемо побудувати і що для цього потрібно?» Якщо потрібна актуальна платформа, оновлення перестає бути окремим технічним проєктом. Це перший етап продукту, якого клієнт насправді хоче.

Laravel 13, наприклад, приносить офіційний Laravel AI SDK: генерацію тексту, агентів із викликом інструментів, ембединги, роботу з аудіо та зображеннями й інтеграції з векторними сховищами. У ньому ж з'явилася вбудована підтримка векторних запитів для смислового пошуку.

Ці можливості потрібні не всім. Але стара технічна основа може непомітно стати обмеженням для бізнес-ідеї.

БІЗНЕС-ЛОГІКА

Фреймворк це проста частина

Саме тут помиляється більшість оцінок. Клієнт чує «оновлення Laravel» і уявляє заміну версії фреймворку. Але фреймворк зазвичай найпростіша частина. Складне все, що виросло навколо нього.

Старий застосунок це не просто код. Це накопичена бізнес-логіка.

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

Тому ми не вважаємо старий код сміттям лише тому, що він старий.

Перш ніж вирішувати, що може зникнути, зрозумійте, що мусить залишитися.

ДВА ОНОВЛЕННЯ

Зазвичай це два оновлення

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

Другий сюрприз: мажорні версії Laravel пропускати не можна. Сайт на Laravel 7 проходить через 8, потім 9, потім 10 і так далі.

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

Дорого коштує рідко остання версія. Дорого коштують усі версії, які компанія пропустила.

АВТОМАТИЗАЦІЯ

Автоматизація, а не магія

Сервіси автоматичного оновлення існують, і вони справді корисні. Найвідоміший із них Laravel Shift: ціни починаються від $29 за один перехід, а безлімітний тариф для всіх репозиторіїв коштує $2 999 на рік.

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

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

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

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

ШІ І БІЗНЕС

Хто читає бізнес?

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

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

А найнебезпечніші його помилки тихі. Сайт відкривається. Меню працює. Стилі на місці. А тим часом форма заявок перестала доставляти листи.

Тож корисне питання не в тому, чи може ШІ оновити Laravel. Значну частину роботи він автоматизує. Корисне питання: хто звірить результат із реальним бізнесом. Детальніше ми розбирали це у статті «Чи потрібен мені розробник, чи вистачить ШІ?»

ШІ змінює економіку оновлення, але не відповідальність за нього.

ПРИХОВАНІ ВИТРАТИ

Де ховаються гроші

В опитуванні Zend 2026 року команди назвали найбільш трудомісткою частиною переходу тестування (42%), яке випередило рефакторинг (36%). Водночас 32% розробників на PHP в опитуванні JetBrains взагалі не пишуть тестів.

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

Далі закинуті пакети. На тримовному корпоративному сайті, який ми просто зараз оновлюємо з Laravel 7, за одним закинутим пакетом для форм стоїть понад двісті полів в адмінці. Замінити такий пакет означає зачепити двісті бізнес-процесів.

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

НЕВИДИМИЙ ДЛЯ ШІ

Сайт, якого не бачить ШІ

Оновлення рідко зачіпає лише код. Воно зачіпає хостинг, і там ховаються одні з найдорожчих сюрпризів.

Один із них ми знаходимо знову і знову: сайт частково закритий від ШІ-роботів, і ніхто цього не вирішував. Хостинги часто вмикають захист від ботів із налаштуваннями за замовчуванням, які блокують таких роботів, як GPTBot від OpenAI чи агенти Meta. Деякі ще й дописують свої правила в robots.txt, а власник цього не помічає. Для людей сайт працює ідеально. Для ChatGPT, Perplexity чи ШІ-асистента, що допомагає з покупками, його майже не існує.

Ми бачили це на нещодавньому проєкті. Після переїзду на новий хостинг-акаунт GPTBot і роботи Meta отримували помилку 403, а хостинг тихо додав їх до списку заборон у robots.txt. На самому сайті нічого не виглядало неправильним. Щоб це побачити, вистачило однієї перевірки, щоб виправити, кількох налаштувань.

Ціна такої помилки реальна. Сайт, який ШІ-роботи не можуть прочитати, не цитується у відповідях ШІ, описується за застарілими чи чужими джерелами і повністю втрачає новий вид пошукового трафіку.

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

Тому кожне наше оновлення закінчується трьома перевірками, які не мають стосунку до Laravel: які роботи можуть потрапити на сайт, що насправді написано в robots.txt після переїзду і чи налаштована автентифікація пошти. Зробити бізнес зрозумілим для ШІ це окрема дисципліна, і саме їй присвячена наша AEO та GEO-оптимізація.

ІСТОРІЯ

Закопана історія

Є ще одна ціна, яка рідко потрапляє в кошторис. Пам'ять.

Що довше система живе без обслуговування, то менше залишається людей, які пам'ятають, чому вона влаштована саме так. Розробник, який придумав дивний обхідний шлях, міг піти. Менеджер, який замовляв інтеграцію, міг перейти в іншу компанію. Підрядник міг зникнути. Документації могло не бути ніколи.

У якийсь момент хтось відкриває код і питає: «Чому це працює так?» І відповісти вже нікому.

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

ЦІНИ РИНКУ

Скільки бере ринок

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

Ринок відображає цей розкид. Платні аудити починаються приблизно від $299, а багато компаній пропонують безкоштовні «аудити», які на ділі виявляються продажним дзвінком із приблизною оцінкою наприкінці. На іншому полюсі переписати старий застосунок з нуля у 2026 році зазвичай коштує від $80 000 до понад $3 млн, залежно від обсягу коду і прихованої бізнес-логіки.

Корисний висновок простіший: вартість оновлення визначається тим, що всередині системи, а не цифрою після слова «Laravel».

РІШЕННЯ

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

Є три чесні відповіді.

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

У всіх інших випадках «почекати» не нейтральне рішення. Це рішення накопичити більше залежностей, більше невизначеності і більше технічної археології.

НАШ ПРОЦЕС

Як ми це робимо

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

Тому наша робота з модернізації сайтів іде в чіткому порядку:

1. Аудит. Дивимося код, пакети, версії PHP і Laravel, хостинг, володіння, інтеграції і все те, про що легко забути, доки воно не перестане працювати. Клієнт отримує письмовий звіт із планом оновлення, ціною і термінами. Аудит це платний етап: $300 для невеликих і середніх сайтів, від $1 000 для великого e-commerce і складних проєктів. Звіт належить клієнту, з ним можна працювати з нами або з іншою командою.
2. Закрита копія. Тестова копія закрита від пошукових систем на рівні сервера. Ми не експериментуємо на живому бізнесі.
3. По одній версії. Кожен крок фреймворку це окремий коміт, який перевіряється до початку наступного. Якщо щось пішло не так, ми відкочуємося на один крок, а не відновлюємо весь проєкт.
4. Перевірка клієнтом. Клієнт дивиться оновлений сайт до того, як щось зміниться на робочому.
5. Швидка викатка. Вона може бути швидкою саме тому, що вся складна робота зроблена заздалегідь. Одразу після перемикання перевіряємо те, що важливо бізнесу: сайт відкритий для Google, форми доставляють заявки, інтеграції відповідають. Якщо сайт заразом переїжджає на новий хостинг, ідемо за чек-листом переїзду, який пропускає більшість агенцій.
6. Спостереження й опис. Добу стежимо за сайтом після перемикання, передаємо письмовий опис усіх змін і даємо гарантію 30 днів.

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

ПЕРШЕ ПИТАННЯ

Перше питання

Номери версій важливі. Але це не перше питання для бізнесу. Перше питання: що ця система робить для компанії?

Приносить заявки? Приймає оплату? Передає дані в CRM? Керує товарами? Відправляє замовлення на склад? Обслуговує особистий кабінет клієнтів? Публікує контент, який приводить пошуковий трафік? Виконує процес, про який ніхто не пам'ятає, бо він давно став рутиною?

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

Саме тому два сайти на одній версії Laravel можуть коштувати при оновленні зовсім по-різному. Один може бути чистим застосунком із тестами та актуальними залежностями. Інший десятьма роками власної бізнес-логіки.

ЗАЗИРНУТИ ВСЕРЕДИНУ

Головне питання

Якщо ваш сайт працює на старій версії PHP, Laravel, WordPress чи OpenCart, відповідь не обов'язково «оновлюватися». І не обов'язково «переробляти».

Перший крок значно скромніший. Зазирнути всередину.

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

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

Найдорожча застаріла система та, за яку ніхто не хвилюється.

FAQ

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

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

Ні. Laravel оновлюється по одній мажорній версії за раз, наприклад із 7 на 8, потім на 9, і PHP зазвичай доводиться оновлювати разом із ним.

Скільки коштує оновити старий сайт на Laravel?

Залежить від того, що всередині, а не від номера версії. Оновлення на одну версію в доглянутому застосунку може зайняти день; старому застосунку з власним кодом і без тестів спершу потрібен аудит. Аудит невеликих і середніх сайтів у нас коштує $300, великих e-commerce-проєктів від $1 000.

Чи може ШІ або Laravel Shift оновити сайт автоматично?

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

Що дешевше: оновити чи переробити?

Зазвичай оновити. Про переробку варто говорити, коли оцінка оновлення наближається до 60% вартості переробки того самого функціоналу.

Чому мого сайту немає у відповідях ШІ?

Одна з частих причин технічна: хостинг або robots.txt закривають сайт від ШІ-роботів на кшталт GPTBot. Це варто перевіряти після будь-якого переїзду хостингу чи оновлення.

Яку версію PHP використовувати бізнес-сайту у 2026 році?

Підтримувану: PHP 8.3 або новіший надійний вибір. PHP 8.2 отримує виправлення безпеки лише до 31 грудня 2026 року.

Джерела

• PHP Statistics 2026, FOSS Post (W3Techs, php.net, Zend, JetBrains, Patchstack)
• Laravel 13 release notes
• Laravel 9 release notes
• Laravel 13 Released, Laravel News
• Shift + AI: Fully Automated Laravel Upgrades, Laravel News
• Laravel Shift plans
• StackShield vs Laravel Shift
• Upgrading with Laravel Shift, CodeWithSusan
• How Much a Laravel Version Upgrade Costs, Dev Loader
• Laravel Version Upgrade Cost in 2026, Acquaint Softtech
• Laravel Version Upgrades: Why Falling Behind Costs More Every Year, Rocking Tech
• Cost to Rewrite a Legacy Application in 2026, Cadence