При замене или обновлении системы код можно написать заново, а данные — нет. Клиенты, заказы, история операций, документы — это невосполнимый актив, накопленный годами. Поэтому миграция данных — самая ответственная часть любой модернизации: ошибки здесь не «поправим в следующем релизе», а потерянная история бизнеса.
Сначала инвентаризация, потом перенос
Первый шаг — понять, что вообще переносим. Звучит очевидно, но в старых системах данные живут неожиданными путями: часть в основной базе, часть в файлах, часть в соседних сервисах и таблицах, о которых помнит один сотрудник. Инвентаризация выявляет все источники, их владельцев и связи между ними.
Заодно решается вопрос объёма: не всё накопленное нужно в новой системе. Устаревшие записи иногда разумнее отправить в архив, чем тащить в новую структуру — но это должно быть осознанное решение бизнеса, а не случайность переноса.
Маппинг: как старое ложится в новое
Структуры старой и новой систем никогда не совпадают полностью. Маппинг — это карта соответствий: какое поле откуда берётся, как преобразуется, куда попадает. Именно здесь всплывают неудобные вопросы: что делать с полями, которым нет места в новой системе, как разделить данные, которые раньше хранились одной строкой, что считать дубликатами.
На эти вопросы должен отвечать не только разработчик, но и бизнес: за каждым полем стоит процесс, и только его владелец знает, что важно сохранить.
Качество данных: чистить до, а не после
Миграция безжалостно вскрывает накопленный беспорядок: дубликаты клиентов, пустые обязательные поля, телефоны в свободном формате, «тестовые» записи в боевой базе. Переносить хаос в новую систему — значит начать новую жизнь со старыми проблемами. Чистку и нормализацию стоит провести до переноса, пока старая система ещё работает и есть с чем сверяться.
Репетиции и сверка
Боевой миграции должны предшествовать тестовые прогоны на копии реальных данных. Каждый прогон — это проверка скрипта переноса и списка расхождений для разбора. Ключевой инструмент — автоматическая сверка: количество записей, контрольные суммы по важным показателям, выборочное сравнение конкретных объектов до и после.
Репетиции дают ещё одно важное знание — время. Зная, сколько занимает перенос, можно честно спланировать окно миграции и понять, нужна ли стратегия переноса без остановки работы.
План перехода и путь назад
Финальный этап — переключение пользователей на новую систему. Каким бы уверенным ни был тестовый прогон, нужен план отката: возможность вернуться на старую систему, если после переключения обнаружится критичная проблема. Старую систему и резервные копии не отключают сразу — они остаются страховкой и источником для сверки на согласованный период.
Коротко
Успешная миграция — та, которую пользователи почти не заметили: данные на месте, работа продолжается. Такой результат складывается из подготовки, репетиций и сверки, а не из удачи. Если вам предстоит обновление системы с переносом данных, начните с аудита — мы оценим состояние данных и спроектируем безопасный план перехода.