Переводим устаревшую систему на Laravel
без потери данных и трафика
Система работает, но развивать её больше нельзя: разработчиков на старый стек не найти,
правка стоит как проект, а данные расходятся между сервисами. Мы разбираем систему,
восстанавливаем логику и переносим её на современный стек — этапами, не останавливая бизнес.
Начинаем с аудита и карты системы: что переносится, что придётся делать заново,
сколько это займёт и как сохранить поисковый трафик. После аудита можно внедрять
своими силами — план останется у вас.
Посмотрим систему, базу и интеграции. Скажем, какая стратегия подойдёт, что переносится и сколько это займёт.
Ответ 15 мин
Диагностика
Восемь признаков, что система тянет бизнес назад
Модернизация нужна не «потому что технологии устарели», а когда система мешает зарабатывать.
Проверьте, сколько пунктов про вас — это и есть содержание первого созвона.
01
Разработчиков на ваш стек не найти
Технология устарела: специалистов на рынке почти нет, найм превращается в долгий поиск, а старый разработчик — единственный, кто понимает систему.
Чем обходится: Любая доработка ждёт человека, а не наоборот. Бизнес зависит от одного исполнителя.
Что делаем: Переводим на Laravel — самый востребованный PHP-фреймворк: команду можно расширять и заменять без остановки работ.
02
Правка стоит как маленький проект
Изменение в одном месте ломает другое: код связан неявно, тестов нет, а последствия видны только после релиза на прод.
Чем обходится: Задачи откладываются месяцами, продукт не успевает за рынком, стоимость изменений растёт.
Запросы без индексов, кеш в файлах, тяжёлые отчёты на живой базе: в пиковые часы сайт отвечает секундами или отдаёт ошибки.
Чем обходится: Потерянные заказы и заявки, падение позиций в поиске (скорость — фактор ранжирования), нагрузка на поддержку.
Что делаем: Нормализуем схему и индексы, переносим кеш и очереди в Redis, тяжёлые операции уводим в фоновые задачи.
04
Верифицированных обновлений нет
Версия языка или фреймворка не поддерживается, обновлений безопасности не выходит, а хостинги постепенно отказываются от старых сборок.
Чем обходится: Открытые уязвимости, риск утечки данных клиентов и штрафов, невозможность переехать на нормальную инфраструктуру.
Что делаем: Актуальный PHP и поддерживаемые зависимости, обновления по регламенту, проверка уязвимостей в CI.
05
Логика живёт в голове одного человека
Документации нет, комментарии устарели, часть правил «все знают». Уход или отпуск ключевого сотрудника останавливает изменения.
Чем обходится: Проект замирает, восстановление знаний стоит денег и времени, риск ошибок в критичных местах.
Что делаем: Восстанавливаем логику по коду, базе и интервью, описываем документально и передаём команде — знание перестаёт быть личным.
06
Данные расходятся между системами
Остатки, цены и статусы приходят из разных источников и не сходятся: интеграции держатся на ручных выгрузках и скриптах по расписанию.
Чем обходится: Ошибки в заказах и учёте, ручные сверки, недоверие к отчётам и решения «по ощущениям».
Что делаем: Описываем обмены явно (что, когда, по какому правилу), добавляем журнал синхронизации, повторные попытки и алерты на расхождения.
07
Безопасность на уровне «и так сойдёт»
Запросы собираются конкатенацией, пароли хранятся слабым хешем, файлы доступны по прямым ссылкам, доступы не разграничены.
Чем обходится: Утечка персональных данных, претензии по 152-ФЗ, репутационные и финансовые потери.
Что делаем: Подготовленные запросы, современное хеширование паролей, разграничение ролей, закрытые файлы, аудит доступа к данным.
08
SEO и производительность упираются в потолок
Дубли адресов, отсутствие микроразметки, медленная отдача и отсутствие нормальной структуры: трафик есть, но растёт не так, как мог бы.
Чем обходится: Недополученный органический трафик — самый дешёвый канал, который недогружен.
Что делаем: Проектируем структуру URL и правила индексации, добавляем микроразметку, ускоряем отдачу. Всё это — часть миграции, а не отдельный проект.
Стратегии
Четыре способа модернизации — и как выбрать
«Переписать всё» — не единственный вариант и часто не самый выгодный. Стратегию выбираем
на аудите: она зависит от того, работает ли система сейчас и сколько бизнес готов ждать.
Постепенное вытеснение
Strangler Fig
Чаще всего подходит
Когда подходит
Система работает и приносит деньги, останавливать её нельзя, но развивать на старом стеке уже невыгодно.
Как это выглядит
Рядом с текущей системой поднимается Laravel-контур: отдельные разделы (каталог, заказы, личный кабинет) переводятся на него по одному и начинают обслуживать свой трафик. Старый код остаётся до тех пор, пока новый раздел не доказал корректность.
На что смотреть
Требует дисциплины: какое-то время живут два контура. Нужен явный план переключения, иначе переход затягивается.
Система деградировала настолько, что поддержка дороже развития, или бизнес-логика сильно изменилась и старый код мешает.
Как это выглядит
Собираем новую систему целиком на Laravel, переносим данные и запускаем её параллельно: трафик переключается в один момент, с полной картой редиректов и планом отката.
На что смотреть
Дольше до первого результата и выше требования к точности переноса: ошибки видны сразу, а не постепенно.
Логика в целом устраивает, а проблемы — в надёжности, безопасности и скорости, а не в архитектуре.
Как это выглядит
Не переписываем всё: закрываем уязвимости, добавляем тесты на критичные сценарии, выносим тяжёлые операции в фон, оптимизируем запросы, наводим порядок в окружениях и бэкапах.
На что смотреть
Не решает кадровую проблему: если стек непопулярен, найти разработчиков всё равно сложно.
Ядро менять нельзя: лицензионная система, самописный ERP, учётный контур, который работает и не подлежит замене.
Как это выглядит
Старое ядро остаётся источником правды, но вокруг него появляется слой на Laravel: новый интерфейс, интеграции, отчёты, личные кабинеты. Обмен — через API, шину событий или очереди с журналом.
На что смотреть
Ограничения ядра остаются: если оно медленное или закрытое, это придётся учитывать в дизайне решения.
Структура старого кода: приложение проектируется заново, а не переносится файлами.
Поведение «баг в баг»: часть старого поведения — следствие ошибок, повторять его не нужно.
Расширения, плагины и модули один в один: их функции реализуются нативным кодом, часть оказывается лишней.
Ручные операции и разовые скрипты, которые выполнялись вручную годами: их заменяют нормальные процессы.
Устаревшие библиотеки и подключения без менеджера зависимостей.
Прямые доступы к файлам и базе: в новой системе доступы разграничены и журналируются.
План
Как проходит модернизация
Шесть этапов, каждый заканчивается проверяемым результатом. Старый контур не выключается,
пока новый не докажет, что считает и отдаёт данные правильно.
011–3 недели
Аудит и карта системы
Разбираем текущую систему: схема данных, точки входа, интеграции, задачи по расписанию, реальные бизнес-правила. На выходе — карта системы и оценка объёма.
022–3 недели
Архитектура и план переноса
Проектируем схему данных на Laravel, выбираем стратегию перехода, описываем этапы, критерии приёмки и план по SEO-редиректам.
032–6 недель
Стенд и перенос данных
Поднимаем новый контур, переносим данные, сверяем суммы, связи и справочники. Разрабатываем модули, начиная с тех, что дают деньги.
04по ситуации
Параллельная работа
Новый и старый контуры работают одновременно: разделы переключаются по одному после сверки. Пользователи не замечают переезда.
052–5 дней
Переключение трафика
Переводим домен, включаем 301-редиректы по карте URL, проверяем sitemap, счётчики и цели. Контролируем индексацию и ошибки.
062–4 недели
Стабилизация и передача
Следим за метриками, правим найденное, обучаем команду, передаём документацию, доступы и регламенты.
SEO и трафик
Трафик из поиска не должен просесть
Главный страх при переезде — потерять позиции. Поэтому SEO-часть делается до переключения
и контролируется после: это не «посмотрим, что будет».
Карта URL до переезда
Собираем все адреса старой системы из базы, sitemap и логов: карточки, категории, пагинация, фильтры, старые ЧПУ.
301-редиректы 1:1
Совпадающие адреса сохраняем, остальные закрываем постоянными редиректами — без «главной страницы вместо товара».
Метаданные и заголовки
Переносим title, description, H1 и тексты, а не генерируем заново: поиск уже знает эти страницы.
Микроразметка
Товары, хлебные крошки, отзывы, FAQ — разметка сохраняется и валидируется заново на новом контуре.
Sitemap и robots
Актуальная карта сайта, корректные правила обхода, отсутствие закрытых от индексации нужных страниц.
Счётчики и цели
Метрика, аналитика, цели и события переносятся и проверяются до переключения, чтобы не потерять статистику.
Мониторинг после релиза
Следим за ошибками 404/500, индексацией и позициями первые недели — редиректы и обход проверяются на живом трафике.
Что меняется по факту
Скорость отдачи
Страницы отвечают быстрее: нормализованная схема, индексы, кеш и очереди вместо тяжёлых синхронных операций.
Стоимость изменений
Доработки перестают быть проектом: код разделён на слои, есть тесты и понятная структура.
Найм и передача
Проект на популярном стеке ведёт любая PHP-команда, а не один человек с историей правок.
Устойчивость
Обновления и релизы проверяются на стенде, откат — в одну команду, бэкапы проверяются на восстановление.
Стек
На что переводим: Laravel и вокруг
Открытые технологии без лицензий за редакции и модули. Стек подобран так, чтобы систему
могла развивать любая команда, а не только автор.
Интерфейсы без перезагрузок: админка, таблицы, формы, фильтры.
PostgreSQL или MySQL
Нормализованная схема, индексы под реальные запросы, реплики для отчётов.
Redis
Кеш, сессии и очереди вместо файлового кеша и cron-скриптов.
Horizon и очереди
Фоновые задачи с повторами, приоритетами и мониторингом.
Тесты и CI/CD
Покрытие критичных сценариев, отдельные окружения, релизы и откаты в одну команду.
Наблюдаемость
Логи, метрики и алерты: видно ошибки и деградацию до жалоб пользователей.
API и интеграции
Явные контракты обмена с 1С, платежами, доставкой, CRM и маркетплейсами.
Конкретные системы
Миграция с конкретных платформ
У каждой системы свои ловушки: где-то логика спрятана в модификаторах, где-то — в сниппетах,
а где-то нет даже документации. Ниже — разборы по частым платформам: что переносится,
что нет и на что смотреть.
Система работает и приносит деньги, но развивать её на текущем стеке дорого или невозможно
Есть данные, которые нельзя потерять: история заказов, платежей, заявок
Есть человек со стороны бизнеса, который знает процессы и может отвечать на вопросы
Готовы к этапной работе: переезд идёт месяцами в зависимости от объёма
Важен поисковый трафик и его нужно сохранить при переключении
Не подойдёт
Система устраивает и менять её не собираются — достаточно закрыть уязвимости и наладить бэкапы
Объём кода небольшой: иногда дешевле написать заново по описанию процессов, чем переносить
Нет доступа к коду и базе и получить их невозможно: без этого оценить объём нельзя
Ждут переезд «за две недели» без потери функциональности: так не бывает, и мы не будем это обещать
Проект планируется закрыть в ближайшие месяцы
Чего мы не обещаем
Переноса «один в один, включая все баги»: часть поведения старой системы повторять вредно.
Миграции без участия вашей команды: нам нужен человек, который знает процессы и правила.
Нулевого риска при полном рерайте: риск снимается этапами, тестами и параллельной работой, а не обещаниями.
Гарантии конкретных позиций в поиске: мы гарантируем корректные редиректы и метаданные, а не место в выдаче.
Бесплатной поддержки старого контура после переключения: какое-то время он живёт, но не бесконечно.
Зато обещаем обратное: план с этапами и критериями приёмки, доступ к коду и данным с первого дня,
документацию в составе работ и прямое «нет», если модернизация вам не нужна.
Форматы работ
Четыре способа начать
Можно взять только аудит и внедрять своими силами. Можно мигрировать этапами. Можно
переписать систему целиком. Выбор зависит от состояния кода и от того, сколько бизнес
готов ждать — и мы говорим прямо, если достаточно укрепить текущую систему.
Аудит и план миграции
Нужно понять объём работ, риски и стоимость до принятия решения.
Карта системы и данных
Схема данных на Laravel
План этапов и критерии приёмки
План SEO-редиректов
Оценка сроков и бюджета
фиксированная стоимостьАудит можно внедрять своими силами
Объём данных и качество: дубли, битые связи и справочники требуют отдельного этапа очистки
Количество кастомной логики в старом коде: бизнес-правила восстанавливаются по коду и интервью
Число интеграций: 1С, платежи, доставка, CRM, маркетплейсы — каждая описывается и проверяется
Требования к сохранению SEO: карта URL, редиректы и метаданные по тысячам страниц
Выбранная стратегия: постепенное вытеснение дешевле полного рерайта, но длиннее по срокам
Требования к контуру: облако или ваша инфраструктура, изоляция данных, аудит доступа
Как мы снижаем риск переезда
Аудит перед сметой: объём считаем по коду и данным, а не «на глаз»
Этапы с критериями приёмки: результат проверяется на каждом шаге
Параллельная работа контуров: старый не выключается до сверки
Полные бэкапы и план отката перед каждым переключением
Код и данные у вас: смена подрядчика не обнуляет проект
Вопросы
Частые вопросы про модернизацию
Стратегия, данные, SEO, сроки и стоимость — отвечаем так же, как ответили бы на первом созвоне.
Чем отличается модернизация от миграции?
Миграция — перенос данных и логики из одной системы в другую. Модернизация шире: это ещё и решение о том, что вообще делать с системой — постепенно вытеснять модулями, переписать целиком, укрепить и оставить или изолировать ядро и нарастить вокруг новый слой. Мы начинаем с аудита именно для того, чтобы выбрать стратегию, а не продать разработку по умолчанию.
Что делать, если старый автор кода недоступен?
Это частая ситуация. Логику восстанавливаем по базе данных, логам, документам и тому, как системой пользуются сотрудники. Все допущения фиксируем письменно и согласуем с вами — так спорные места становятся явными до разработки, а не после запуска.
Как выбирается стратегия модернизации?
По трём факторам: работает ли система и можно ли её останавливать, насколько кастомна логика и сколько бизнес готов ждать первого результата. Если система приносит деньги и логика сложна — почти всегда выбираем постепенное вытеснение. Если поддержка дороже развития и логика изменилась — полный рерайт. Иногда достаточно укрепить текущую систему, и мы скажем об этом прямо.
Сколько это стоит и как формируется смета?
Смета собирается из четырёх составляющих: аудит и карта системы, проектирование и подготовка данных, перенос и разработка, переключение и стабилизация. Аудит фиксируется по цене заранее, остальное считается этапами с понятным результатом на каждом. По объёму работ миграция сопоставима с разработкой нового проекта: опубликованные пакеты разработки начинаются от 149 000 ₽, крупные системы считаются индивидуально.
Как вы гарантируете, что данные не потеряются?
Три уровня контроля. Первый — инвентаризация и правила целостности до переноса. Второй — перенос на стенд и сверка по ключевым таблицам вручную, а не только автоматическим отчётом. Третий — параллельная работа контуров: старый не выключается, пока новый не подтвердил суммы и связи. Плюс полные бэкапы перед каждым этапом.
Что будет с SEO при полном рерайте?
Карта URL собирается из базы, sitemap и логов сервера. Совпадающие адреса сохраняются один в один, остальные закрываются 301-редиректами. Метаданные, заголовки и микроразметка переносятся, а не генерируются заново. После переключения мы 2–4 недели следим за ошибками 404/500, индексацией и позициями и правим найденное.
Как переносится база данных при миграции?
Схема переносится целиком, включая историю операций: заказы, платежи, заявки, справочники. Перед переносом проверяем целостность данных и чистим дубли. На новом контуре схема нормализуется: появляются типы, ограничения и внешние ключи, которые не дают создавать несогласованные записи. Сверку делаем выборочно вручную по ключевым таблицам, а не только отчётом из скрипта.
Как гарантируется, что трафик из поиска не просядет?
Карта URL собирается до переезда: из базы, sitemap и логов сервера. Совпадающие адреса сохраняются один в один, остальные закрываются 301-редиректами. Метаданные, заголовки и микроразметка переносятся, а не генерируются заново. После переключения мы следим за ошибками, индексацией и позициями — обычно это 2–4 недели наблюдения.
Что происходит с интеграциями: 1С, платежи, доставка, CRM?
Каждая описывается до разработки: что передаётся, как часто, что считается успехом и как видеть ошибки. В новой системе обмены становятся явными: журнал синхронизации, повторные попытки, алерты. Платёжные модули подключаем на тестовых аккаунтах до переключения трафика.
Можно ли обойтись без полного переноса?
Да. Варианты: укрепить текущую систему (закрыть уязвимости, добавить тесты, навести порядок в бэкапах), вынести отдельный модуль на Laravel и связать через API или шину, либо рефакторить по частям. На аудите мы говорим прямо, какой путь дешевле — иногда это отказ от полного переноса.
Сколько стоит миграция?
Стоимость зависит от объёма данных, числа интеграций, количества кастомной логики и требований к сохранению SEO. Аудит и план миграции фиксируются по цене заранее, дальше проект считается этапами с понятным результатом на каждом. По объёму работ миграция сопоставима с разработкой нового проекта — но с сохранением данных, истории и трафика.
Что будет с сотрудниками, которые работают в старой системе?
Мы меняем систему, а не процессы: админка собирается под их задачи, а обучение входит в проект. Обычно новая админка нравится больше: понятные формы, живые таблицы, отчёты без участия разработчика. Для сложных мест пишем короткие инструкции.
Кому принадлежат код и данные после миграции?
Вам. Код, схема данных, документация, доступы и инфраструктура оформляются на вас с самого начала. Мы не удерживаем проект в своём контуре: его можно передать другой команде, а документация описывает систему так, чтобы ей мог заняться любой PHP-разработчик.
Что нужно от нас для старта?
Доступ к исходному коду и базе данных (или их копиям), список интеграций и сервисов, контакт человека, который знает бизнес-логику и процессы, и данные о том, что критично не потерять при переезде. Дальше мы работаем сами и показываем промежуточные результаты.
Следующий шаг
Разберём вашу систему и назовём сроки
Начнём с аудита: код, база, интеграции, задачи по расписанию и то, что критично сохранить.
На выходе — стратегия, план этапов, срок и смета. Аудит можно внедрять своими силами.
Мы используем необходимые cookie для работы сайта и форм. Аналитические cookie
(Яндекс.Метрика, включая запись сессий) подключаем только с вашего согласия —
от него можно отказаться. Подробнее:
Политика использования cookie
и
обработка персональных данных.
Настройки cookie
Выберите, какие категории cookie можно использовать. Необходимые отключить нельзя:
без них не работают формы и сессия.