Миграция с Magento 1 на Magento 2: перенос данных, тем и SEO

Миграция Magento 1 на 2: что ломается без плана переноса

Магазин на устаревшей версии Magento держится до первого конфликта: расширения под старую ветку перестают получать обновления, а часть уже несовместима с новой архитектурой. Подключить новый модуль оплаты или доставки становится задачей с обходным путём, а исправлений безопасности для ядра не выходит — уязвимости закрывают правками в чужом коде.

Поддержка старой версии упирается в людей и в отсутствие стенда. Инженеров, которые помнят её устройство, всё меньше, документация по кастомизациям часто неполная, и любая доработка идёт без тестового контура, повторяющего боевой каталог и настройки.

Вторая точка отказа — данные. Ручная выгрузка каталога и заказов даёт рассинхрон: часть товаров уезжает без атрибутов, у части теряются связи с категориями, история заказов переносится неполной. Покупатель видит пустую карточку или заказ без статуса — и уходит к конкуренту.

Третья — адреса. Если перенос интернет-магазина идёт без карты редиректов, старые адреса товаров и разделов отдают 404, а накопленные ссылки и позиции в поиске обнуляются за считанные недели. Восстанавливать их потом дороже, чем построить схему адресов заранее.

План переноса связывает эти части в один порядок работ: инвентаризация расширений, перенос данных с проверкой сходимости, карта адресов, тестовый контур на копии каталога. Разбираем, как это закрывается по шагам.

Что даёт перенос на поддерживаемую платформу: эффект в цифрах

Перенос с Magento 1 на актуальную ветку меняет не внешний вид, а поведение системы под нагрузкой. На старой схеме каталог собирается из нескольких слоёв кэша, а любая правка атрибута запускает полную переиндексацию: страница категории с фильтрами отвечает всё дольше по мере роста числа товаров и значений атрибутов.

После переноса выборку обслуживает подготовленный слой, индексы перестраиваются по частям, и отклик каталога на списках и фильтрах сокращается в несколько раз — при этом он не деградирует по мере роста ассортимента. Тяжёлые комбинации фильтров перестают быть узким местом.

Отдельно меняется устойчивость к всплескам: пик от рассылки или распродажи раньше выбивал часть страниц и корзину, потому что чтение и запись конкурировали за одни ресурсы. Теперь чтение вынесено на отдельные узлы, запись идёт через очереди, и всплеск растягивается по времени, а не превращается в отказ.

Срок вывода изменений тоже сокращается: правка шаблона, настройки или промо-блока вместо ручной выкладки на сервер уезжает в продакшн одним проходом, а откат к предыдущей сборке возвращает рабочее состояние без разбора файлов вручную. Индексация, прогрев кэша и сборка статики идут по расписанию, поэтому доля ручных операций падает — вместе с классом отказов, когда обновление стороннего модуля перезаписывало тему или ломало оформление заказа.

Варианты миграции Magento 1 на 2: сравнение подходов

Выбор варианта переноса определяет не размер каталога, а допустимое окно недоступности витрины и объём кастомной логики. Magento 1 и Magento 2 — разные ядро, структура базы и слой шаблонов, поэтому модули и темы переносятся не копированием, а переписыванием под новую архитектуру. Отсюда три рабочих сценария с разной ценой перехода.

Плата за ускорение всегда переносится в другое место. На параллельной витрине это стоимость синхронизации и двойного тестирования, на одномоментной — риск длительного восстановления при сбое. Подход фиксируем после инвентаризации модулей и замеров нагрузки на текущую систему, иначе выбор остаётся теоретическим.

Этапы переноса: аудит, схема данных, настройка, проверка

Переход с Magento 1 на 2 — это не переустановка, а перенос данных, от которых зависит работа магазина: каталога с историей цен, заказов за несколько лет, клиентов с адресами и скидками. Восстановить их после потери нечем, поэтому работы идут по шагам, и каждый следующий начинается после приёмки предыдущего.

1. Аудит данных магазина. Инвентаризируем каталог, наборы и значения атрибутов, категории, клиентов, адресные книги, заказы, правила цен и статические страницы: считаем объёмы, находим дубли, битые ссылки на изображения и данные, которые переносить не нужно.
2. Схема соответствия сущностей. Сводим таблицу «атрибут-источник → атрибут-приёмник» с типом значения, обязательностью и набором атрибута. Отдельно описываем статусы заказов, группы клиентов и типы адресов — расхождения здесь дают потери при переносе.
3. Настройка окружения. Разворачиваем целевую платформу на актуальной ветке: язык, СУБД, поисковый сервис, кэш и очереди сообщений; настраиваем индексацию и раздельные контуры для разработки и репетиции переноса.
4. Пробный прогон на копии. Переносим данные на полную копию базы и медиафайлов, замеряем время и ресурсы, ловим ошибки типов и кодировок. Прогонов обычно два: после первого схема соответствия уточняется.
5. Сверка данных после переноса. Сравниваем количество записей по каждой сущности, выборочно — цены, остатки, историю заказов, привязку адресов и изображений, проверяем редиректы старых ссылок.
6. Переключение и сопровождение. Догоняем прирост данных, меняем маршрутизацию, включаем мониторинг, следим за индексацией и работой корзины; первое время держим прежнюю версию доступной для отката.

Передаваемые артефакты: конфигурации, схемы данных, регламенты

Сдача миграции Magento 1 на 2 — это не только работающий сайт, но и набор артефактов, по которым ваша команда дальше ведёт проект без нас. Всё передаём в репозиторий рядом с кодом: файлы версионируются, изменения проходят ревью, а не живут в переписке и памяти отдельных людей.

Перечень согласуем до старта работ, чтобы приёмка шла по списку, а не по ощущениям. Ниже — минимум, который остаётся у заказчика после вывода старого сайта из эксплуатации.

• Конфигурации контуров — параметры тестовой и боевой среды, переменные, порядок сборки: локальная копия проекта поднимается по инструкции за один прогон.
• Карта переноса данных — соответствие «источник → назначение» для товаров, категорий, заказов, клиентов и отзывов, правила преобразования и поведение при повторном запуске.
• Политики доступа и разделения ролей — матрица прав в панели управления, кто может менять каталог и выгружать данные, порядок выдачи и отзыва доступов.
• Правила обработки адресов — карта постоянных перенаправлений со старых ссылок, приоритеты при конфликтах, журнал битых адресов после переключения.
• Регламент обновлений — ветки, окна релизов, порядок применения обновлений платформы и расширений, точки отката до предыдущего рабочего состояния.
• Инструкции для команды — развёртывание, где смотреть журналы, как провести откат, что делать при инциденте, плюс чек-лист приёмки по ключевым сценариям.

Кейс переноса: каталог и заказы переехали без потери позиций

Магазин с каталогом около 12 тысяч позиций и историей заказов за несколько лет работал на Magento 1 — торговать нужно было без остановки, поэтому перенос каталога, клиентов и заказов готовили заранее, а переключение витрины делали в короткое окно низкого трафика.

Что изменили

Каталог переносили через схему соответствия атрибутов: старые наборы разложили по новым, а товарные связи пересобрали по внешним идентификаторам, а не по названиям — иначе комплекты и сопутствующие позиции распадались. Историю заказов перенесли с сохранением связки «клиент — заказ — позиции», статусы и комментарии менеджеров остались читаемыми в личном кабинете, а не превратились в архивный дамп.

Отдельно занимались сохранением адресов страниц: 96% карточек и категорий оставили прежний вид, остальные закрыли постоянным редиректом по карте соответствий — обход поисковых роботов не упёрся в тупики, а накопленные внешние ссылки продолжили вести на те же товары.

Метрики до и после

Отклик каталога под пиковой нагрузкой сократился с секунд до долей секунды: выдача с фильтрами перестала «зависать» на перелистывании. Обновление ассортимента из прайса поставщика раньше занимало часы ручных правок на партию — теперь это одна операция импорта с проверкой расхождений. В первые сутки после переключения витрина отработала пиковый трафик без отказов корзины и оформления, а расхождений между остатками и принятыми заказами не зафиксировали.

Что делать, если часть данных уже перенесена вручную?

Начинать миграцию заново, если половина каталога уже перенесена своими силами, дороже, чем свести две базы. Сначала фиксируем источник истины по каждому типу сущностей: каталог и контент ведём в новой системе, заказы и история клиентов до момента переключения остаются в старой.

Дубли ищем не по внутренним идентификаторам — в Magento 1 и Magento 2 они между собой не связаны, — а по естественным ключам: артикул, URL-ключ, привязка к поставщику. По ним строится карта соответствия «старый идентификатор — новый», и она же становится рабочей для всей дальнейшей дозагрузки данных.

Сложнее со связями товаров и категорий. При ручном переносе позиция попадает в каталог, но теряет привязку к наборам атрибутов, значения справочников и изображения: товар в базе есть, а в фильтрах и на витрине его нет. Эти связи восстанавливаем по карте соответствия, а не повторным заполнением вручную.

Заказы переходного периода — отдельный риск. Долить их списком нельзя: ломается сквозная нумерация, история статусов и связь с аккаунтами покупателей. Поэтому срез берётся на момент переключения и переносится инкрементально, с дедупликацией по номеру заказа и дате оформления.

Дозагрузка данных делается идемпотентной: повторный запуск не создаёт копий и не задваивает остатки. Итог проверяем сверкой — число позиций, доля товаров без категории, заказы, оставшиеся без привязки к клиенту. Расхождения в частичном переносе видны до запуска, а не после.

Совместимость расширений, интеграций и адресов страниц

Перед стартом заказчик обычно опасается не за данные, а за три вещи: расширения, которые в новой ветке платформы не работают, интеграции со складом и оплатой и адреса страниц, накопленные поисковым трафиком. Порядок работ здесь обратный привычному: сначала инвентаризация модулей и карта адресов, потом перенос контента — иначе каталог и разделы придётся переделывать дважды.

Перенос с Magento 1 на актуальную ветку второй версии ведём по функциональности, а не по названиям модулей: для каждого расширения фиксируем, какую задачу оно закрывает, какая доля сценариев реально используется и есть ли готовая замена. Остальное закрываем доработкой через штатный механизм расширения или отдельным модулем, чтобы обновления платформы не ломали логику.

Как переживают перенос интеграции со складом и оплатой?

Обмен выносим в отдельный слой: платформа обращается к нему через штатные интерфейсы, внешние системы — через программный интерфейс обмена. Заказы и остатки синхронизируем с защитой от повторной обработки, журналом и повторными отправками, чтобы сбой на одной стороне не давал двойных списаний. До переключения трафика обе стороны прогоняем в тестовом контуре на копии данных.

Сохранятся ли адреса страниц и структура разделов?

Снимаем карту адресов старого сайта, сопоставляем один к одному с новой структурой и отдаём постоянными перенаправлениями — без цепочек из нескольких переходов. Категории, фильтры, разбивка на страницы и карта сайта получают отдельные правила. После переключения сверяем выгрузку из панели вебмастера: поисковик должен видеть новые адреса, а не ошибки.

Обсудим задачу: с чего начинается перенос магазина

Обсуждение задачи начинается не с оценки, а с инвентаризации: сколько в магазине товаров, атрибутов и вариантов, какие расширения и правки в ядре держат логику продаж, как устроены интеграции. Без этих вводных оценка объёма работ превращается в догадку, а план переноса ломается на первом же нестандартном модуле — поэтому разговор о переносе с Magento 1 на актуальную ветку ведём в плоскости фактов.

Что нужно подготовить к обсуждению:

• выгрузку каталога: число товаров, категорий, атрибутов и вариантов;
• список расширений, тем и доработок ядра — с пометкой, что критично для продаж;
• интеграции: склад, учётная система, службы доставки, платёжные шлюзы, рассылки;
• структуру адресов и правила их формирования — база для карты редиректов;
• отчёт по трафику и точкам входа из поиска за последний год;
• доступы к серверам, репозиториям и панелям, ограничения по окну переноса;
• процессы, которые нельзя останавливать: заказы, выгрузка прайсов, остатки.

На выходе первого этапа вы получаете план переноса с разбивкой по работам, карту данных и адресов, перечень рисков и порядок проверок. Если часть данных недоступна, обозначьте это на старте — уточним состав вводных и вернёмся с оценкой объёма работ. Дальше согласуем сроки и состав команды и начнём с пробного переноса на тестовый контур.