История вопроса:
Миграция данных — критический этап крупных ИТ-проектов, особенно когда происходит переход с устаревших информационных систем (legacy) на новые решения. Ошибки в формализации требований могут привести к потере важной информации или долгому простою при запуске новой системы (чаще всего при large-scale внедрениях). В истории есть печальные кейсы падения банков именно из-за провалов в миграции!
Проблема:
Неясность форматов источников и назначения, различия в структуре данных, несопоставимость справочников, ошибки в маппинге и противоположные ожидания бизнес-команды и технического интегратора — основные причины проблемных миграций. Вымышленная или недостаточно детализированная документация приводит к невозможности отследить, какие данные критичны, какие можно агрегировать, а какие нельзя переносить в принципе.
Решение:
Системный аналитик проводит ревизию данных на стороне источника вместе с владельцами бизнес-процессов; составляет подробную карту данных (data mapping), определяет, какие атрибуты подлежат обязательной миграции, а какие нет. Документирует допущения по качеству данных (чистота, полнота), определяет правила трансформации (например, изменение формата дат, валют, кодировок). Для критичных полей внедряется тестовая выборочная миграция и сценарии обратной проверки (reconciliation). На каждом этапе параллельно оформляются инструкции по откату и критерии успешности миграции.
Ключевые особенности:
Достаточно ли сверить форматы данных между системами для успешной миграции?
Нет. Даже при совпадении форматов возможны несовпадения в бизнес-смысле данных, валидности справочников, семантике значений. Нужен бизнес и технический аудит каждого поля.
Можно ли ограничиться миграцией только "самых востребованных" данных?
Нет. "Редкие" данные могут быть бизнес-критичны для отдельных юзер-процессов (например, для старых договоров, страховок). Всё должно фиксироваться в requirements.
Нужно ли предусматривать возможность отката миграции?
Обязательно — даже при 100% тестах возможны критичные ошибки после go-live, rollback'и — обязательная часть документации.
Негативный кейс: При миграции наследственной банковской системы аналитик согласовал перенос только основных таблиц, не уточнив бизнес-смысл старых неиспользуемых справочников. В результате после запуска клиенты обнаружили проблемы с историей сделок за предыдущие годы.
Плюсы:
Минусы:
Положительный кейс:
Аналитик совместно с бизнесом и ИТ провёл ревизию всех массивов, оформил отдельные требования на перенос "редких" данных, согласовал сценарии валидации и rollback. Миграция прошла успешно, ни одной критической претензии не возникло.
Плюсы:
Минусы: