Как перенести приложение магазина на новый backend без потери клиентских данных

20.10.2026 15 мин чтения

---

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

Что входит в перенос приложения на новый backend

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

Три слоя, которые затрагивает перенос

• Хранение данных. Клиенты, заказы, бонусы, адреса, согласия переезжают в новую базу с другой структурой таблиц.
• Логика и контракты обмена. Методы, которые вызывает приложение, как правило меняют адреса, форматы ответов и правила авторизации.
• Внешние связи. Учётная система, платёжный шлюз, службы доставки, рассылки и аналитика подключаются заново. О согласованности цен и остатков между системами мы писали в материале про интеграцию приложения с 1С, про источник данных об остатках — в обзоре систем складского учёта.

Приложение в сторах и минимальная версия

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

Инвентаризация данных: что именно переносим

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

Реестр клиентских данных приложения магазина

Данные, которые переносить не нужно

Технические журналы, кэш, открытые сессии и служебные флаги остаются в старой системе. Чем меньше персональных данных переезжает, тем короче проверка: переносят то, на что есть основание и срок хранения — по принципам обработки из статьи 5 закона 152-ФЗ.

Карта идентификаторов старой и новой системы

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

Таблица соответствия ключей

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

Правила склейки дубликатов

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

Порядок загрузки по зависимостям

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

• Заказы ссылаются на клиента.
• Начисления — на заказ.
• Возврат — на платёж.

Пароли, входы и привязки соцсетей

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

Перенос хешей с перезаписью при первом входе

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

Вход по одноразовому коду, когда форматы несовместимы

Если старый формат хеша новая система не проверяет, пароли не переносят. Клиент входит по коду на подтверждённый телефон или почту и задаёт пароль заново. Такой сценарий требует предупреждения в приложении и дежурства поддержки в первые сутки. Массовая рассылка новых паролей письмом не применяется.

Привязки соцсетей и токены сессий

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

Бонусный счёт, уровни и сроки сгорания баллов

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

Состав переноса по лояльности

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

Заморозка начислений на время окна

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

История заказов, платежей и чеков

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

Глубина истории и архив

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

Карта статусов

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

Платежи и сохранённые карты

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

Три схемы параллельной работы двух систем

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

Схемы перехода на новую серверную часть

Источник истины в каждый момент времени

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

Выбор окна и сезон

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

Протокол сверки данных

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

Контрольные показатели сверки до и после переноса

Три уровня проверки

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

Кто подписывает результат сверки

Ответственность за результат сверки распределяют так:

• Руководитель ИТ — полнота загрузки.
• Финансовая служба — бонусные обязательства.
• Маркетинг — согласия на рассылки.
• Клиентский сервис — выборочная проверка карточек.

Протокол с подписями закрывает спор «данные потеряны или их не было».

План отката и точка невозврата

Условия отката описывают до старта, пока нет давления сроков. Готовый план снимает спор о терпимости расхождений в ночь переключения.

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

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

Старая система в режиме только чтения

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

Точка невозврата

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

Этапный план переноса: шесть шагов

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

Шаг 1. Инвентаризация данных

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

Шаг 2. Карты соответствия

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

Шаг 3. Пробный перенос на копии

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

Шаг 4. Параллельная работа и сверка

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

Шаг 5. Переключение и первые сутки

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

Шаг 6. Вывод старой системы из эксплуатации

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

Частые ошибки переноса

Шесть ошибок встречаются чаще остальных, и каждая видна клиенту.

• Перенос без карты идентификаторов. Повторная загрузка создаёт дубликаты клиентов.
• Сброс пароля всем без предупреждения. Поток обращений приходится на сутки переключения.
• Бонусы одним числом. Сроки сгорания теряются, списания считаются неверно.
• Окно в высокий сезон. Любое расхождение совпадает с пиком заказов.
• Сверка без согласованных показателей. Спор о потерянных данных в этом случае не закрывается.
• Две смены в одном окне. Серверная часть и платёжный шлюз сразу — ошибки оплаты не с чем сравнить.

Итог: что проверить до переключения

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

Готовность к переключению: минимальные требования

С чего начать подготовку

1. Выгрузить объёмы по сущностям и заполнить реестр данных.
2. Прогнать пробный перенос на копии базы и замерить время загрузки.
3. Согласовать протокол сверки и пороги отката с финансами и поддержкой.

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

Источники

• Django: управление паролями и хеширование
• OWASP Password Storage Cheat Sheet
• RFC 6749. The OAuth 2.0 Authorization Framework

Ссылки ведут на действующие версии документации, состав разделов проверен 12 октября 2026 года.