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

Что на самом деле включает обновление 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 13 release notes and support policy, Laravel documentation
• Available Shifts and prices, Laravel Shift
• Laravel 11.x to 12.x Shift, Laravel Shift
• Shifty Plans, Laravel Shift
• PHP & Laravel Upgrade, fixed price, Techimpace
• Laravel Version Upgrade Cost in 2026, Acquaint Softtech
• How Much a Laravel Version Upgrade Costs, Dev Loader
• Laravel Development Cost Guide, hourly rates by region