Как перенести интернет-магазин без остановки продаж

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

При этом само слово «переезд» может означать совершенно разные изменения. Иногда нужно просто перенести сайт на другой сервер. Иногда — сменить CMS. А в крупных проектах речь может идти о постепенной замене старой системы новой или изменении архитектуры с переносом отдельных функций в самостоятельные сервисы.

Во всех этих случаях отличаются объём работ и риски. Но если интернет-магазин уже приносит продажи, появляется общее требование: изменения не должны надолго останавливать работу бизнеса.

И именно поэтому задача «перенести интернет-магазин» сильно отличается от задачи «разработать новый интернет-магазин».

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

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

Что вообще означает переезд интернет-магазина

Само слово «переезд» объединяет несколько достаточно разных сценариев. Иногда это относительно простая техническая операция, практически незаметная для пользователей. В других случаях под переездом скрывается фактически замена значительной части системы.

Поэтому прежде чем планировать миграцию, стоит определить, что именно и куда переезжает.

Переезд на другой хостинг или сервер

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

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

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

Переезд на другую CMS или платформу

Это уже значительно более серьёзная миграция.

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

В таком случае компания может принять решение сменить платформу. Например, один из сценариев, с которыми мы работаем в PUGOFKA, — переезд интернет-магазина с другой CMS на 1С-Битрикс.

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

Переезд на новую версию интернет-магазина

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

Тогда новая версия разрабатывается параллельно со старой.

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

Фактически происходит переезд бизнеса со старой версии системы на новую.

Изменение архитектуры

По мере роста проекта переезжать может не весь интернет-магазин целиком, а отдельные его части.

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

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

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

Иногда переезд объединяет сразу несколько изменений

На практике границы между этими сценариями не всегда такие чёткие.

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

Чем больше изменений происходит одновременно, тем сложнее миграция и тем выше требования к её подготовке.

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

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

Чем сложнее переезд, тем важнее понять, что именно мы переносим

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

Но реальный объём данных почти всегда значительно больше. В системе могут храниться пользователи, адреса доставки, история заказов, статусы, скидки, промокоды, бонусные баллы, отзывы, SEO-поля, связанные товары, остатки, персональные цены и множество других сущностей.

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

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

Не всё со старого сайта нужно переносить как есть

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

Механически переносить всё это в новую систему не всегда разумно. Но и просто удалить всё подозрительное нельзя. Например, снятый с продажи товар может продолжать получать поисковый трафик. Старый URL может находиться в закладках клиентов или на внешних сайтах. Неиспользуемое на первый взгляд поле может участвовать в обмене с ERP.

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

Новый магазин должен развиваться параллельно со старым

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

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

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

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

Особое внимание — заказам во время переключения

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

Представим, что финальный перенос базы начался в 23:00. В 23:07 клиент оформил заказ на старом сайте, а новая версия запускается в полночь. Если механизм миграции этого не учитывает, заказ может остаться только в старой системе.

Для магазина с несколькими заказами в неделю такую ситуацию ещё можно обнаружить вручную. Для крупного e-commerce даже небольшой промежуток способен означать десятки или сотни операций.

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

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

Интеграции нужно проверять на реальных сценариях

Интернет-магазин редко существует самостоятельно. Заказы могут уходить в 1С или ERP, данные о клиентах — в CRM, остатки и цены приходить из учётной системы, платежи обрабатываться внешним сервисом, доставка рассчитываться через API логистических компаний.

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

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

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

Тестовый перенос обязателен

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

Количество товаров совпало? Все категории на месте? Характеристики привязались правильно? Не потерялись изображения? Пользователи могут авторизоваться? История заказов отображается корректно? Цены соответствуют источнику? Сохранились связи между товарами и торговыми предложениями?

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

Перед запуском нужен полноценный прогон покупки

Отдельная проверка — весь путь реального заказа. Не просто «кнопка "Купить" работает», а полный сценарий:

пользователь находит товар → добавляет его в корзину → авторизуется или оформляет заказ → выбирает доставку → оплачивает → получает подтверждение → заказ появляется во внутренних системах → менеджер может с ним работать → статусы корректно обновляются.

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

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

SEO при переезде — отдельный проект внутри проекта

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

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

Для перенесённых страниц настраиваются корректные 301-редиректы. При этом важно не отправлять тысячи старых страниц просто на главную или ближайшую категорию — новая страница должна максимально соответствовать содержанию старой.

Отдельно проверяются Title, Description, H1, canonical, robots.txt, sitemap, пагинация, фильтры и другие элементы, влияющие на индексирование.

Если какие-то страницы решено не переносить, для них тоже нужно определить правильное поведение. SEO нельзя оставлять на момент «когда новый сайт уже будет готов». Карта URL и требования к индексированию должны появиться ещё во время проектирования миграции.

Не стоит одновременно менять вообще всё

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

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

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

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

Нужен план переключения

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

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

Полезно прописывать не только действия, но и ответственных за них. Чем сложнее магазин, тем больше участников может быть задействовано: разработчики, DevOps, специалисты по 1С или ERP, SEO-команда, аналитики, контент-менеджеры, представители бизнеса.

В момент переключения всем должно быть понятно, что происходит и кто принимает решение на каждом этапе.

И обязательно нужен план отката

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

Можно ли быстро вернуть трафик на старую версию? Сколько времени это займёт? Что произойдёт с заказами, которые уже успели появиться в новой системе? Какие данные нужно будет синхронизировать обратно?

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

Лучше выбирать период с минимальной нагрузкой

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

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

После запуска работа не заканчивается

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

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

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

Что значит «без остановки продаж»

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

Ключевой вопрос — не в красивой формулировке zero downtime, а в том, какое влияние переключение окажет на бизнес. Если короткое техническое окно ночью позволяет значительно снизить риск потери заказов и данных, оно может быть разумнее сложной архитектуры ради формальных нулевых секунд простоя.

Задача команды — определить допустимый уровень недоступности и построить миграцию исходя из него.

Переезд — это прежде всего управление рисками

Перенести интернет-магазин технически можно множеством способов. Но хороший план миграции начинается не с выбора инструмента экспорта.

Сначала нужно понять, что бизнес не может позволить себе потерять:

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

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

Именно поэтому перенос работающего интернет-магазина — это не операция «скопировать сайт на новую CMS». Это отдельный проект, в котором новая система должна постепенно принять на себя функции старой, пока бизнес продолжает работать.

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

А для бизнеса продажи всё это время продолжались.