Основные риски переноса данных в SaaS
Перед тем как начинать миграцию, важно понимать, какие именно угрозы стоят за переходом с одной платформы на другую. Мы систематизировали их по пяти категориям.
1. Потеря или повреждение данных. При переносе между SaaS-платформами данные проходят через промежуточные форматы — CSV, JSON, XML. На каждом этапе возможны искажения: сломанные кодировки, обрезанные поля, потеря связей между таблицами. По данным Gartner, в 2025 году около 27% инцидентов при миграции cloud-данных были связаны именно с потерей целостности.
2. Нарушение требований 152-ФЗ. Если ваш бизнес обрабатывает персональные данные российских граждан, переход на новую платформу может изменить географию хранения. Проверьте, где физически расположены серверы нового провайдера и соответствует ли это требованиям статьи 18 152-ФЗ о локализации данных.
3. Проблемы с интеграцией. Большинство компаний используют SaaS не изолированно, а в связке с CRM, ERP, системами аналитики. Смена платформы может разорвать существующие API-интеграции. На miniwebsansar.com мы регулярно сталкиваемся с ситуациями, когда компании недооценивают количество зависимостей между сервисами. Рекомендуем до начала миграции составить полную карту зависимостей и проверить доступность API нового провайдера.
4. Финансовые риски. Скрытые комиссии за экспорт данных, штрафы за досрочное расторжение, стоимость дополнительных лицензий — всё это может существенно превысить бюджет проекта. Запросите у текущего провайдера полный расчёт стоимости экспорта, а у нового — детализацию всех платежей на первые 12 месяцев.
5. Бизнес-непрерывность. Если миграция затрагивает критичные бизнес-процессы (обработку заказов, работу с клиентами), простой даже в несколько часов может обернуться потерей выручки. Оцените допустимое время простоя и согласуйте окно миграции с ключевыми подразделениями.
Таблица проверки критериев рисков
Чтобы системно оценить каждый риск, выполните следующие шаги.
1. Соберите данные от текущего и нового провайдера по каждому критерию из таблицы ниже.
2. Сопоставьте полученные значения с пороговыми уровнями.
3. Зафиксируйте все пункты, попавшие в зону «Красный флаг», — они станут основанием для отказа или дополнительных требований в ТЗ.
| Критерий | Минимальный порог | Желательный уровень | Красный флаг |
|---|---|---|---|
| Целостность данных | 99% записей перенесены без ошибок | 99,9% + автоматическая верификация | Любые потери в базе клиентов |
| Соответствие 152-ФЗ | Серверы в РФ, есть обработка ПДн | Актуальный аудит + СОПД | Серверы за рубежом без локализации |
| API-совместимость | Базовые методы CRUD доступны | Полный набор + вебхуки + документация | Нет API или только ручной экспорт |
| SLA на время простоя | Не более 4 ч планового простоя | Миграция без простоя + откат | SLA не предусмотрен |
| Стоимость миграции | В пределах бюджета ± 15% | Фиксированная цена в ТЗ | Неизвестные доплаты |
Документы для проверки перед миграцией
Редакция miniwebsansar.com рекомендует запросить у текущего и нового провайдера следующий пакет документов. Этот список мы составили на основе отдельного материала — Какие документы запросить перед переносом данных.
1. Соглашение об обработке персональных данных (СОПД). Убедитесь, что новый провайдер готов подписать СОПД и что условия обработки соответствуют вашей политике конфиденциальности. Проверьте, указан ли перечень категорий субъектов ПДн и цели обработки.
2. Техническая спецификация хранения. Запросите документ с описанием архитектуры хранения: тип хранилища, уровень репликации, регион размещения, протоколы шифрования (at rest и in transit). Подробнее об этом читайте в разделе Сравнить условия хранения данных в облаке.
3. Аудиторское заключение или сертификат. Наличие сертификата ISO 27001, SOC 2 Type II или прохождения аудита по 152-ФЗ — показатель зрелости провайдера. Мы рекомендуем проверять актуальность заключения: документ не старше 12 месяцев.
4. SLA с графиком восстановления. Изучите заявленные метрики: время восстановления (RTO), точка восстановления (RPO), процент доступности. Для критичных систем мы рекомендуем RTO не более 4 часов и RPO не более 1 часа.
5. Регламент миграции данных. Новый провайдер должен предоставить пошаговый регламент перехода: форматы выгрузки, инструменты, сроки, ответственные. Проверить соответствие SaaS требованиям 152-ФЗ поможет наш отдельный материал Проверить соответствие SaaS требованиям 152-ФЗ.
> По данным Роскомнадзора, в 2025 году количество проверок соблюдения 152-ФЗ в отношении облачных сервисов выросло на 35% по сравнению с 2024 годом. Это делает документальную готовность провайдера критически важным фактором при выборе.
Вопросы и ответы
Как долго обычно занимает оценка рисков перед миграцией SaaS?
По нашему опыту, полная оценка рисков для среднего бизнеса (до 500 пользователей, до 5 интеграций) занимает от 5 до 10 рабочих дней. В это время входит сбор документов от провайдеров, проверка соответствия 152-ФЗ, аудит API и согласование бюджета. Для крупных компаний с множеством подключённых сервисов процесс может растянуться на 3–4 недели.
Какие документы обязательны, а какие — желательны?
Обязательными мы считаем Соглашение об обработке персональных данных (СОПД), SLA с описанием уровня доступности и техническую спецификацию хранения. Без этих документов подписание ТЗ с новым провайдером сопряжено с юридическими и техническими рисками. Сертификаты ISO 27001 или SOC 2 — желательны, но не критичны, если провайдер предоставляет альтернативные доказательства безопасности.
Можно ли провести миграцию данных без простоя бизнес-процессов?
Да, при условии, что новый и старый провайдеры поддерживают параллельную работу. Мы рекомендуем сценарий «синхронизации с переключением»: сначала настраивается двусторонняя синхронизация данных, затем в согласованное окно выполняется финальное переключение. При грамотном планировании время реального простоя можно сократить до 15–30 минут.