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

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

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

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

Что уточнить до выбора подрядчика

1. Какие данные переносятся

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

2. Откуда и куда выполняется перенос

Например: из старой CRM в новую SaaS-платформу, из Excel в мобильное приложение, из самописной базы в веб-сервис, из нескольких систем в единый кабинет.

3. Есть ли доступ к исходной базе

Подрядчик должен заранее сказать, нужен ли доступ к SQL-базе, API, административной панели, CSV/XLSX-экспорту, резервной копии или облачному хранилищу.

4. Какой объём данных

Важно считать не только строки, но и вложения. 20 000 карточек клиентов и 300 ГБ файлов — это разные по сложности задачи.

5. Какие поля обязательны

Например: телефон, email, ID клиента, дата регистрации, статус заказа, сумма, источник заявки, согласие на рассылку.

6. Что делать с ошибками и дублями

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

7. Как проверяется полнота переноса

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

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

Ориентиры по срокам и стоимости

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

Для небольшого цифрового сервиса перенос может стоить условно от 30 000–80 000 ₽, для проекта с API, файлами и проверкой связей — от 100 000–300 000 ₽ и выше. Если подрядчик обещает сложную миграцию «за день и без ТЗ», это повод запросить детализацию.

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

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

Базовая, оптимальная и срочная сметы

Запросите у подрядчика не одну цену, а три варианта:

1. Базовая смета

Только обязательный перенос: таблицы, основные поля, минимальная проверка. Подходит, если система не критична и объём небольшой.

2. Оптимальная смета

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

3. Срочная смета

Перенос за 3–7 дней или быстрее, с приоритетной командой. Важно отдельно зафиксировать, что именно сокращается: сроки анализа, тестирования или поддержки. Срочность не должна означать отказ от резервной копии.

Когда перенос не подходит или его лучше отложить

Перенос данных в новый цифровой сервис лучше не начинать, если:

• нет утверждённого технического задания;

• неизвестно, какие данные считаются обязательными;

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

• в базе много дублей, битых файлов и пустых полей;

• новый сервис ещё не готов принимать данные;

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

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

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

В таких случаях сначала нужно провести аудит данных. Иногда дешевле потратить 2–5 дней на очистку базы, чем потом вручную исправлять ошибки после запуска.

Что может пойти не так

Типовые риски: нет ТЗ, размытые сроки, устные правки, скрытая стоимость материалов, неподходящий формат файлов или отсутствие поддержки.

К частым проблемам относятся:

• Потеря связей между объектами

Например, заказы перенесены, но не связаны с клиентами.

• Дубли пользователей

Один и тот же клиент появляется несколько раз из-за разных email или телефонов.

• Ошибки кодировки

Имена, адреса и комментарии отображаются некорректно.

• Неверные даты и часовые пояса

Особенно важно для заказов, платежей, бронирований и логов.

• Не перенесены вложения

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

• Сломались роли доступа

Пользователи видят не свои данные или не могут войти в сервис.

• Нет плана отката

Если импорт прошёл с ошибками, непонятно, как вернуться к рабочему состоянию.

Контекстная внутренняя ссылка: здесь уместна ссылка на материал о том, как составить техническое задание для цифрового сервиса.

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

Контекстная внутренняя ссылка: полезно добавить переход к разбору поддержки и сопровождения программного продукта после запуска.

1. Исходные данные

• [ ] Есть список систем, из которых нужно забрать данные.

• [ ] Понятен объём: количество записей, файлов, таблиц, пользователей.

• [ ] Есть пример выгрузки в CSV, XLSX, JSON, XML или SQL.

• [ ] Определены обязательные поля.

• [ ] Отмечены поля, которые можно не переносить.

• [ ] Есть резервная копия исходной базы.

• [ ] Понятно, кто отвечает за доступы к старой системе.

2. Новый цифровой сервис

• [ ] Новый сервис готов к приёму данных.

• [ ] Созданы необходимые справочники и роли.

• [ ] Настроены поля, статусы, категории, права доступа.

• [ ] Проверены ограничения по формату файлов и размеру вложений.

• [ ] Есть тестовый контур или безопасная среда для пробного импорта.

3. Техническое задание

В ТЗ желательно зафиксировать:

• перечень переносимых сущностей;

• соответствие полей «старая система → новый сервис»;

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

• правила обработки пустых и ошибочных значений;

• требования к кодировке и форматам дат;

• порядок переноса файлов;

• критерии успешной приёмки;

• сроки каждого этапа;

• ответственных со стороны заказчика и подрядчика.

4. Смета и сроки

Проверьте, что в смете отдельно указаны:

• анализ исходных данных;

• подготовка маппинга полей;

• пробный импорт;

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

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

• исправление ошибок;

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

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

• условия срочного выполнения за 3–7 дней.

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

5. Безопасность и документы

Минимальный набор:

• договор или оферта;

• техническое задание;

• смета;

• NDA при работе с персональными или коммерческими данными;

• акт выполненных работ;

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

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

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

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

6. Проверка результата

После переноса не ограничивайтесь визуальным осмотром. Нужна измеримая проверка:

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

• проверить 20–50 случайных карточек;

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

• проверить 5–10 пользователей с разными ролями;

• открыть выборочные вложения;

• проверить поиск и фильтры;

• проверить авторизацию;

• запросить отчёт об ошибках импорта;

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

Хорошая практика — сначала сделать тестовый перенос на 5–10% данных или на одной группе пользователей. Это позволяет обнаружить проблемы до основного запуска.

7. Гарантия и поддержка

Уточните:

• сколько дней действует гарантия на ошибки миграции;

• какие ошибки исправляются бесплатно;

• сколько раундов правок включено;

• как быстро подрядчик отвечает после запуска;

• кто исправляет ошибки в данных, если они были в исходной базе;

• сколько стоит повторный импорт;

• что считается новой задачей, а не гарантийной правкой.

Для большинства проектов разумный минимум — 3–14 дней поддержки после переноса. Для бизнес-критичных сервисов лучше предусмотреть дежурство в день запуска и на следующий рабочий день.

Какие вопросы обязательно задать подрядчику перед переносом данных?

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

Нужно ли делать резервную копию перед миграцией?

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

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

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

Что важнее: цена или опыт подрядчика?

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

Можно ли перенести данные без технического задания?

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

Что делать, если часть данных не подходит по формату?

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

Кто должен проверять результат — заказчик или подрядчик?

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

Как понять, что подрядчик занижает стоимость?

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

Что включить в запрос подрядчику?

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