Вопросы и ответы

Перенос данных в новый цифровой сервис: чек-лист вопросов перед стартом проекта

Автор и проверка: Алексей Воронов, редакционный координатор ormobil.com · Факты, документы, риски и применимость · Обновлено: 05 сентября 2025 г.

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

Критерии выбора

Что именно переносится

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

Для проекта миграции обычно выделяют несколько групп данных:

• пользователи и профили;

• заказы, заявки, обращения, бронирования;

• платежные статусы и история операций;

• товары, услуги, тарифы, справочники;

• файлы, изображения, вложения;

• настройки ролей и прав доступа;

• история коммуникаций: уведомления, комментарии, обращения в поддержку;

• технические логи, если они нужны для аудита или гарантийной поддержки.

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

В каком состоянии находятся источники

До старта проекта нужно понять, откуда будут забираться данные. Источником может быть CRM, ERP, старая база сайта, мобильное приложение, Excel-файлы, облачная таблица, 1С, платежный шлюз, складская система или архив SQL-дампов.

Проверьте:

• есть ли актуальная схема базы данных;

• кто владелец каждого источника;

• доступны ли административные права;

• можно ли сделать экспорт без остановки сервиса;

• есть ли ограничения API;

• совпадают ли данные в интерфейсе и в базе;

• за какой период нужны записи: например, за 12 месяцев, 3 года или весь срок работы сервиса.

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

Какие требования есть к новому сервису

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

До миграции стоит зафиксировать:

• какие поля обязательны в новой системе;

• какие значения допустимы;

• как обрабатываются пустые поля;

• что делать с дублями пользователей;

• как переносить пароли и авторизацию;

• нужно ли сохранять старые ID;

• как будут сопоставляться статусы старого и нового сервиса;

• какие данные должны быть доступны в мобильном приложении сразу после запуска.

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

Сроки, бюджет и ответственность

Для небольшого сервиса миграция может занять 3–7 рабочих дней, если данные хорошо структурированы, есть доступы, понятная схема и небольшой объем записей. Для системы с несколькими источниками, историей платежей, файлами и мобильным приложением срок часто составляет 2–6 недель.

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

В смете должны быть отдельными строками:

• аудит источников;

• подготовка карты данных;

• разработка скриптов миграции;

• очистка и нормализация;

• тестовый перенос;

• сверка результата;

• промышленная миграция;

• резервное копирование;

• поддержка после запуска;

• доработки при расхождениях.

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

Таблица проверки

| Что проверить | Зачем это нужно | Какой результат должен быть |

|---|---|---|

| Список источников данных | Чтобы не забыть CRM, платежи, файлы, мобильные профили или архивы | Реестр источников с владельцами и доступами |

| Форматы выгрузки | Чтобы заранее понять, нужны ли конвертация и очистка | CSV, XLSX, JSON, XML, SQL-дамп или API-экспорт описаны в ТЗ |

| Обязательные поля | Чтобы новый сервис не отклонял импорт | Таблица соответствия старых и новых полей |

| Дубли и невалидные записи | Чтобы не перенести мусор в новый продукт | Отчет по дублям, пустым полям, ошибочным email и телефонам |

| Права доступа | Чтобы не раскрыть клиентские или внутренние данные | Матрица ролей: администратор, менеджер, клиент, поддержка |

| Персональные данные | Чтобы соблюсти требования к хранению и обработке | Назначены ответственные, проверены согласия и политика обработки |

| Пароли и авторизация | Чтобы пользователи могли войти после запуска | Выбран сценарий: сброс паролей, SSO, токены, повторная авторизация |

| Файлы и вложения | Чтобы документы, фото и акты не потерялись | Проверены ссылки, размер файлов, доступность хранилища |

| История операций | Чтобы пользователи видели заказы, оплаты и обращения | Определен период переноса: например, последние 24 месяца |

| Тестовая миграция | Чтобы выявить ошибки до запуска | Перенесена выборка 5–10% данных или отдельный тестовый сегмент |

| Приемка | Чтобы зафиксировать успешный результат | Подписан акт приемки или чек-лист сверки |

| Откат | Чтобы вернуться к рабочему состоянию при сбое | Есть резервная копия и план rollback |

Сравнение вариантов

Вариант 1. Ручной перенос

Ручной перенос подходит, если данных мало: например, до 500–1000 записей, небольшое количество клиентов, простая структура и нет критичной истории операций. Такой вариант часто используют при запуске MVP, переносе справочников, услуг, базовых карточек товаров или начального списка пользователей.

Плюсы:

• быстро стартует;

• не требует сложной разработки;

• удобно для небольших объемов;

• можно параллельно очищать данные.

Минусы:

• высокий риск человеческих ошибок;

• сложно повторить процесс;

• плохо подходит для регулярной синхронизации;

• трудно доказать полноту переноса.

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

Вариант 2. Импорт через файлы

Импорт через CSV, XLSX, XML или JSON — распространенный вариант для CRM, каталогов, заказов, справочников и пользовательских профилей. Он подходит, когда старый сервис умеет выгружать данные, а новый — принимать их по шаблону.

Плюсы:

• понятный формат для согласования;

• можно протестировать на выборке;

• удобно хранить версии файлов;

• проще согласовать с заказчиком и исполнителем.

Минусы:

• возможны ошибки кодировки;

• теряются связи между сущностями, если нет ID;

• требуется контроль форматов дат, телефонов, валют и статусов;

• большие файлы могут импортироваться медленно.

Пример проверки: даты должны быть приведены к единому формату, например `YYYY-MM-DD`, телефоны — к международному формату, email — проверены на синтаксис, а денежные значения — на валюту и количество знаков после запятой.

Вариант 3. Миграция через API

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

Плюсы:

• можно переносить данные порциями;

• легче контролировать ошибки;

• подходит для поэтапного запуска;

• возможна синхронизация старой и новой системы.

Минусы:

• нужны лимиты, токены и документация API;

• скорость зависит от ограничений сервиса;

• сложнее тестировать;

• требуется журналирование запросов и ответов.

Если API ограничивает, например, 1000 запросов в час, а нужно перенести 500 000 записей, сроки миграции нужно считать заранее. Иначе проект может остановиться не из-за разработки, а из-за технического лимита.

Вариант 4. Прямая миграция из базы в базу

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

Плюсы:

• высокая скорость;

• подходит для больших объемов;

• можно сохранить связи и идентификаторы;

• удобно автоматизировать повторный запуск.

Минусы:

• нужен опытный разработчик или DBA;

• ошибки могут затронуть весь массив;

• требуется резервное копирование;

• опасно работать без тестового контура.

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

Когда перенос данных не подходит и что может пойти не так

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

Перенос может быть не лучшим вариантом, если:

• данные сильно загрязнены и требуют отдельного проекта очистки;

• нет владельца данных со стороны бизнеса;

• старая система не позволяет сделать корректную выгрузку;

• новый сервис еще не стабилизирован;

• нет тестового контура;

• не описаны правила приемки;

• не определено, что делать при ошибках после запуска.

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

Отдельный риск — перенос персональных данных без проверки прав доступа. Например, менеджер должен видеть только своих клиентов, клиент — только свои заказы, а администратор — полный набор данных. Если роли не проверить заранее, после запуска возможна утечка информации.

1. Зафиксируйте цель миграции

Ответьте письменно:

• зачем переносим данные;

• какие бизнес-процессы должны заработать после запуска;

• какие данные нужны в первый день;

• какие можно перенести позже;

• что считается успешным результатом.

Хорошая формулировка: «После запуска нового личного кабинета пользователь должен войти по email, увидеть заказы за последние 24 месяца, текущий статус, оплаченные счета и доступные документы».

Плохая формулировка: «Перенести старую базу в новый сервис».

2. Подготовьте техническое задание

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

В ТЗ желательно указать:

• перечень источников;

• формат выгрузок;

• карту соответствия полей;

• правила обработки дублей;

• правила валидации;

• сценарии ошибок;

• сроки тестовой и промышленной миграции;

• ответственных за приемку;

• гарантийный период исправлений.

3. Проверьте качество данных

До начала разработки попросите выгрузить тестовый фрагмент: например, 1000 пользователей, 1000 заказов, 100 платежей и 100 файловых вложений. На этой выборке можно увидеть реальные проблемы.

Проверяйте:

• процент пустых обязательных полей;

• количество дублей;

• некорректные телефоны и email;

• разные форматы дат;

• битые ссылки на файлы;

• несоответствие статусов;

• записи без владельца;

• старые тестовые данные.

Если в тестовой выборке 10–15% строк требуют ручного исправления, это уже отдельная задача по очистке, которую нужно включать в сроки и бюджет.

4. Согласуйте правила преобразования

Данные редко переносятся «один к одному». Чаще их нужно преобразовать:

• объединить имя и фамилию или, наоборот, разделить;

• привести телефоны к единому формату;

• заменить старые статусы новыми;

• объединить дубли клиентов;

• пересчитать бонусы;

• привязать заказы к новым филиалам;

• изменить формат адресов;

• перенести файлы в новое хранилище.

Все правила лучше оформить в таблицу соответствия. Это может быть отдельный документ: «Карта миграции данных», «Mapping table» или приложение к ТЗ.

5. Назначьте владельцев данных

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

Назначьте владельцев по зонам:

• клиенты — отдел продаж или CRM-менеджер;

• заказы — операционный менеджер;

• платежи — бухгалтерия или финансовый специалист;

• документы — юрист или администратор;

• роли доступа — руководитель направления;

• мобильное приложение — product owner или технический владелец.

6. Проведите тестовую миграцию

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

Минимальная проверка:

• импорт завершился без критических ошибок;

• количество записей совпадает;

• связи между пользователями и заказами сохранены;

• файлы открываются;

• статусы отображаются корректно;

• пользователи не видят чужие данные;

• мобильное приложение получает нужные данные через API;

• отчеты формируются без искажений.

Для сервиса с активными пользователями тест стоит проводить минимум на 5–10% данных или на отдельном сегменте: один город, один филиал, одна группа клиентов, один тариф.

7. Подготовьте план запуска и отката

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

В плане запуска укажите:

• дату и время начала;

• кто останавливает старый сервис;

• кто запускает скрипты;

• кто проверяет результат;

• сколько времени отведено на приемку;

• что делать при критической ошибке;

• когда принимается решение об откате;

• как уведомляются пользователи и поддержка.

План отката должен быть реальным, а не формальным. Если резервная копия есть, но никто не проверял восстановление, это не полноценная защита.

8. Определите приемку и гарантию

Приемка должна быть измеримой. Недостаточно открыть новый сервис и сказать: «Вроде работает». Нужны контрольные показатели.

Примеры критериев приемки:

• перенесено 100% активных пользователей;

• расхождение по заказам — 0 критичных записей;

• не менее 99% файлов доступны;

• платежные статусы совпадают с исходной системой;

• 20 контрольных пользователей проверены вручную;

• роли доступа соответствуют матрице;

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

Гарантийный период на исправление ошибок после миграции стоит фиксировать отдельно. Для небольших проектов это может быть 5–10 рабочих дней, для сложных сервисов — 30 дней и более.

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

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

Сколько времени занимает перенос данных в новый цифровой сервис?

Простой перенос структурированных данных может занять 3–7 рабочих дней. Миграция из нескольких источников с API, файлами, правами доступа, историей операций и тестированием обычно занимает 2–6 недель. Срок зависит от качества источников, объема данных и количества правил преобразования.

Какие документы нужны перед началом миграции?

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

Можно ли переносить пароли пользователей?

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

Что важнее: скорость переноса или качество данных?

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

Кто должен принимать результат миграции?

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

Что делать, если после запуска обнаружились ошибки?

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

Как понять, что подрядчик готов к миграции?

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