Перенос товаров, клиентов и заказов: что теряется на самом деле

Часть 6 из 7 · Серия «Старый сайт — новая рабочая система»

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

Формально не соврали: строки переехали все. Просто «перенести все записи» и «не потерять данные» — разные утверждения, и разница между ними обнаруживается уже после запуска.

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

Поля, которым нет аналога

Главный источник потерь. В старой системе поле было, в новой такого нет — и данные некуда положить.

Типичные случаи:

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

Составные поля. Один «адрес» строкой вместо города, улицы и дома. Пока адрес просто печатается на бланке — не беда; как только понадобился расчёт доставки по региону, придётся разбирать.

Служебные поля прошлой эпохи. «Код в старой 1С», «менеджер-куратор», «признак акции 2019». Часть из них мертва, часть неожиданно оказывается единственным связующим звеном с учётной системой.

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

Товары: что вскрывается при переносе

Перенос каталога работает как ревизия — вскрывается всё, что накопилось.

Дубли. Один и тот же товар заведён дважды-трижды разными менеджерами с разными названиями. Пока каталог большой, этого не видно; при переносе они всплывают.

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

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

Категории. Товар лежит в трёх разделах сразу, есть разделы без товаров, есть товары вне разделов.

Всё это переносить в новую систему бессмысленно — мусор надо разобрать до переезда, иначе он переедет и продолжит мешать.

Клиенты: три открытия

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

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

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

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

Заказы: сколько истории нужно на самом деле

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

Статусы придётся сопоставить. В старой системе их было четырнадцать, в новой шесть. Нужна карта соответствия — иначе половина истории окажется в статусе «не определён».

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

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

Как проверить полноту

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

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

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

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

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

Проходим по списку «что нельзя потерять» — тому самому, который составляли в третьей части. По каждому пункту отдельная проверка.

Проверку делает заказчик, а не только исполнитель. Разработчик проверит, что данные перенеслись; правильно ли они перенеслись — знаете только вы.

Что делать с тем, что не переехало

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

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

Частые вопросы

Можно ли перенести данные автоматически?

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

Сколько времени занимает перенос?

Сам перенос — обычно недолго. Основное время уходит на подготовку данных до него и на проверку после.

Нужно ли чистить каталог до переноса или после?

До. Иначе вы платите за перенос мусора, а чистить всё равно придётся.

Что делать, если у товаров нет артикулов?

Проставить. Это трудоёмко, но без артикулов не будет нормального обмена с учётной системой, а значит, вернётся ручная работа, ради ухода от которой всё и затевалось.

Обязательно ли просить клиентов менять пароли?

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

Что дальше

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

Перенос данных с проверкой полноты — обычная часть работы над сайтом: siteko.net/development.