Почему запуск “с чистого листа” — это чаще про миграцию, чем про новизну

Примерно 30–40% наших проектов — это запуск с чистого листа. Иногда так и есть: никакого кода, никаких интерфейсов, просто идея и желание начать. Но на практике чаще всего «чистый лист» оказывается с заметками на полях. Даже если нет легаси-кода и серверов в подвале — почти всегда есть пользователи, бонусы, заказы, каталоги — всё это должно куда-то переехать. И чем раньше мы начнём думать об этом, тем спокойнее будет запуск.

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

Каталог и бонусы: выглядит просто, но с нюансами
С каталогом товаров всё обычно проще. Чаще всего он приходит из внешней системы: 1С, Excel, XML, PIM — не суть. Там всё более-менее понятно. Согласовали структуру — и вперёд. Ошибки начинаются тогда, когда база плохо структурирована, а на старом проекте это держалось на костылях. Выгружаем — и получаем не структуру, а хаос.

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

Миграция пользователей
Сами пользователи переносятся несложно. Для большинства систем есть штатные механизмы. Но есть один подводный камень — пароли. Если ваша старая платформа (например, тот же Битрикс) хранила пароли в виде хешей — вы не сможете их просто вытащить.

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

Заказы — самая глубокая связка
Одна из самых сложных структур при миграции. У заказа есть статус, история оплат, доставки, корзина, покупатель, иногда — привязка к внешним системам. Это не одна таблица, целый набор сущностей, каждая из которых состоит из своего набора данных.

Мы в своей практике чаще всего идём по пути прямого импорта: сначала переносим пользователей, затем — связанные с ними заказы. Главное — правильно сопоставить ID старых и новых сущностей, иначе вы получите тысячи «висячих» заказов, которые ни к кому не привязаны.

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

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

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

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