Миграция интернет-магазина на новую платформу и как сохранить позиции

Эта статья про ситуацию, когда интернет-магазин уже работает на собственном движке и вы подумываете сменить его на другой. WooCommerce на что-то иное, OpenCart на Laravel, старая самописная система на современную платформу.

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

Сначала отделите симптом от причины

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

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

Что часто чинится без переезда

Медленная страница может быть следствием тяжелой темы, неоптимизированных изображений, неудачного запроса или слабого сервера. Конфликт после обновления часто возникает из-за устаревшего модуля без поддержки. Хаос в админке обычно вызван избыточными правами и дублированными полями. Все это исправляется аудитом, чисткой зависимостей и сменой процесса развертывания.

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

Что указывает на системное ограничение

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

Второй сигнал это невозможность безопасно менять систему. В коде нет четких границ между частями, модули переписывают одни и те же события, тестовой среды нет, а обновление возможно только во время долгого простоя. Часть технического долга можно убрать. Если же перестройка фундамента приближается по объему к новому решению, сравнение платформ становится рациональным.

Когда переезд будет лишним

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

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

Осторожно относитесь к аргументу «новая платформа быстрее». Скорость зависит от реализации, данных, инфраструктуры и нагрузки. Нужен целевой показатель для конкретных страниц и операций и тест на реальном каталоге. Общее обещание доказательством не является.

Если вы еще на стадии выбора между движками, а не переезда, посмотрите сравнение: OpenCart или WooCommerce.

Чем смена собственного движка отличается от ухода с аренды

Разница не косметическая, и именно из-за нее планы, написанные под один случай, не работают в другом.

• Данные у вас уже есть. Не надо успевать выгрузить до закрытия аккаунта: база под рукой, и можно делать сколько угодно тестовых прогонов.
• Старую систему можно оставить живой. Это основа плана отката, которого при уходе с аренды обычно нет.
• Структура адресов под вашим контролем. На новом движке ее можно сохранить точно такой, какой она была, а не принимать ту, что навяжет платформа.
• Интеграции надо переписывать. Учет, доставка, оплата подключались к старому движку, и каждую связь придется собрать заново.
• Модули не переезжают вообще. Все, что делали плагины, либо есть в новой системе, либо пишется. Эту статью сметы недооценивают чаще всего.

Фиксация эталона до начала работ

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

• Полный обход сайта. Реестр всех страниц: категории, фильтры, товары, статьи, служебные. С кодами ответа, каноническими адресами, заголовками и описаниями.
• Страницы с реальным трафиком. Список страниц с показами за двенадцать месяцев, полученный через API Google Search Console. Выгрузка прямо из отчета обрезается до 1000 строк, а в интернет-магазине таких страниц бывает значительно больше. Так ни одна коммерческая страница не потеряется из-за того, что о ней забыли.
• Контрольные позиции. Снимок текущих позиций по основному пулу запросов, чтобы после переезда было с чем сравнивать.
• Карта интеграций. Что с чем соединено, в какую сторону идут данные, как часто, и кто заметит, если связь оборвется.
• Копия базы и файлов. Полная, работоспособная, с проверенным восстановлением. Храните ее там, откуда можно восстановить сайт.

Сведите это в одну таблицу с типом страницы и новым адресом. Дальше правила применяются группами, а исключения рассматриваются отдельно.

Стратегия адресов

Главное решение всего переезда принимается здесь и почти не переигрывается потом.

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

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

Третий вариант это уже авария. Он случается тогда, когда об адресах вспоминают после релиза.

Перенос данных между движками

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

• Карта соответствия полей. Что в старой системе было атрибутом, в новой может быть вариацией. Что было текстом, должно стать значением из словаря.
• Идентификаторы сохраняются. Артикул и внутренний код это основа связей с учетом и каналами продаж. Их смена ломает интеграции молча.
• Тестовый прогон на полном каталоге. На всем объеме, потому что проблемы проявляются именно на нетипичных позициях, которых на двадцати товарах не видно.
• Отчет о расхождениях. Сколько товаров перенеслось, сколько отклонено и почему. Без отчета разница обнаруживается через месяц.
• Клиенты и заказы. История покупок и пароли переносятся, если алгоритм новой системы это позволяет. Если нет, сброс паролей планируют заранее и предупреждают людей.

Объем этих работ прямо влияет на смету интернет-магазина, и именно он обычно оказывается больше ожиданий, потому что модули старой системы никто не считал.

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

День переключения

В день релиза порядок действий должен быть записан заранее и выполняться по пунктам, а не по памяти.

• Снизьте TTL записей DNS. До пяти минут, за сутки до старта. Это дает возможность быстро вернуться назад.
• Заморозьте изменения каталога. На короткое согласованное окно, чтобы финальная синхронизация была полной.
• Сделайте финальный перенос. Заказы и изменения остатков, пришедшие на старый интернет-магазин в день переключения, должны оказаться в новой системе.
• Переключите записи. И сразу проверьте, что сертификат работает на всех поддоменах.
• Снимите запрет индексации. Тестовую среду закрывали от поисковиков, и на рабочем сайте этот запрет нужно снять сразу после переключения.
• Пройдите контрольный список. Главная, категория, товар, корзина, оформление заказа и несколько старых адресов.

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

План отката

Это то преимущество, которого нет при уходе с аренды, и именно поэтому им грех не воспользоваться.

• Старый интернет-магазин остается еще на тридцать дней. На отдельном сервере, в рабочем состоянии, с базой. Магазин можно снова включить, если понадобится откат.
• Низкий TTL до и после. Это сокращает задержку возврата, но срока не гарантирует: часть промежуточных кешей держит старый адрес дольше объявленного TTL.
• Граница решения названа заранее. Это конкретные условия, при которых команда откатится.
• Дежурный в первые часы. Разработчик и администратор с оговоренным временем реакции и правом принять это решение.

Отдельно продумайте, что делать с заказами, которые придут в новый магазин до отката. Они не должны исчезнуть вместе с переключением назад.

Типичные фатальные ошибки

• Об адресах вспомнили после релиза. Худшее из возможного: старые страницы исчезают из индекса, накопленный вес обнуляется.
• Тестовый интернет-магазин оставили открытым. Копия на поддомене без запрета индексации размывает основной домен и создает дубли.
• Запрет индексации не сняли. Рабочий интернет-магазин остался закрытым от поисковиков, и страницы постепенно выпадают из индекса.
• Модули не посчитали. Смету составили только на перенос данных, а половина функций жила в плагинах, которых в новой системе нет.
• Мета-теги сгенерировали заново. Шаблонные заголовки вместо сохраненных уникальных это потеря работы, которую делали годами.
• Старую систему выключили сразу. Плана отката не стало в тот момент, когда он понадобился.

Что делать после переключения

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

Это отдельная работа со своим порядком, и она разобрана в продолжении: техническое SEO после переезда интернет-магазина.

Выводы

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

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

Пришлите нам адрес магазина и опишите, что именно его ограничивает. Мы посмотрим структуру, нагрузку и журналы и скажем, нужен ли переезд или достаточно убрать узкие места на месте. Если переезд нужен, соберем карту адресов и карту интеграций до начала работ и возьмем миграцию в рамках разработки интернет-магазинов.