Перенос данных: чек-лист, риски и следующий шаг

Что подготовить перед переносом данных в новый сервис

Прежде чем начинать выгрузку, команда duubesoft.com рекомендует пройти три подготовительных этапа. Каждый из них снижает вероятность потери данных до минимума.

1. Аудит текущей базы данных. Зафиксируйте точный объём данных: количество записей, размер в гигабайтах, число таблиц или коллекций. Например, база CRM с 150 000 контактов и 1,2 млн записей активности весит около 8 ГБ в PostgreSQL. Эта цифра станет вашим ориентиром при проверке после переноса.

2. Сопоставление форматов и полей. Составьте маппинг — таблицу соответствия полей старой и новой системы. Типичная проблема: в старом сервисе поле «Телефон» хранится в формате +7XXXXXXXXXX (12 символов), а новый сервис ожидает 10 цифр без кода страны. Без маппинга вы получите пустые столбцы или ошибки валидации.

3. Тестовая выгрузка на копии. Создайте тестовую среду и перенесите 5–10 % данных. По результатам теста вы поймёте, есть ли проблемы с кодировкой (UTF-8 vs CP1251), с лимитами API (например, Яндекс.Касса ограничивает выгрузку 1000 записей за один запрос) или с вложенными объектами (вложения, связанные записи).

> По данным отраслевого исследования Gartner, 83 % проектов по миграции данных сталкиваются с задержками из-за некорректного маппинга полей на этапе подготовки.

Не забудьте оформить согласование с владельцами данных. Если вы переносите персональные данные, потребуется уведомление Роскомнадзора (в соответствии с Федеральным законом № 152-ФЗ «О персональных данных» от 27.07.2006, статья 22). Срок уведомления — не позднее 30 дней до начала обработки в новой системе.

Таблица проверки: форматы, объём и совместимость полей

Мы собрали ключевые параметры, которые стоит сверить до запуска миграции. Эта таблица — основа вашего внутреннего документа проверки.

Проверьте также лимиты API нового сервиса. Подробнее о том, как проверить лимиты API при переносе базы клиентов в CRM, мы рассказывали в отдельном материале.

Типичные риски при миграции данных и как их избежать

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

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

2. Нарушение ссылочной целостности. Связи между таблицами (например, «Заказ → Клиент») могут разорваться, если ID записей изменились. Решение: сохраняйте маппинг старых и новых ID в промежуточной таблице.

3. Дублирование записей. При повторном импорте (например, после сбоя) создаются дубли. Решение: настройте уникальные ключи (email, номер телефона, внешний ID) и используйте стратегию «обновить, если существует» (upsert).

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

5. Несоответствие часовых поясов и локалей. Даты и числа могут интерпретироваться иначе (американская запись 07/08/2025 — это июль или август?). Решение: зафиксируйте локаль (ru_RU) и часовой пояс (Europe/Moscow) в конфигурации импорта.

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

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

• Объём базы превышает 500 000 записей или 10 ГБ — ручной перенос слишком рискован и займёт непропорционально много времени.

• Данные содержат персональную информацию (ФИО, телефоны, адреса, паспортные данные) — необходимо соблюдение 152-ФЗ и протоколы обработки.

• Используется более 5 связанных таблиц с вложенными объектами — риск нарушения ссылочной целостности возрастает многократно.

• Требуется миграция в нерабочее время (окно менее 4 часов) — без автоматизации и опытной команды уложиться невозможно.

• После переноса необходима параллельная работа двух систем (синхронизация в реальном времени) — это отдельный интеграционный проект.

По нашему опыту, проект миграции базы из одного SaaS-сервиса в другой при объёме до 200 000 записей занимает от 3 до 7 рабочих дней при работе специалиста. Стоимость начинается от 45 000 ₽ и зависит от сложности маппинга и количества интеграций.

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

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

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

Да, если вы обрабатываете персональные данные российских граждан и меняете оператора обработки (то есть серверы нового сервиса расположены за пределами РФ или вы передаёте данные третьей стороне). Согласно статье 22 Федерального закона № 152-ФЗ, уведомление подаётся не позднее 30 дней до начала обработки. Если серверы нового сервиса находятся в России и вы остаётесь оператором, уведомление может не потребоваться, но лучше получить заключение юриста.

Какой формат резервной копии лучше создать перед миграцией?

Оптимальный вариант — полный дамп базы данных в формате SQL (для реляционных систем) или JSON (для NoSQL), плюс отдельная выгрузка всех бинарных вложений (файлы, изображения, документы). Храните копию в двух локациях: на локальном носителе и в облачном хранилище. Срок хранения — минимум 90 дней после завершения проекта.

Практический контекст — Интеграция с CRM: чек-лист, риски и.