Какие документы запросить перед переносом данных в новый SaaS-сервис?

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

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

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

Минимальный набор документов, который стоит запросить до миграции:

Какие документы запросить у SaaS-поставщика до переноса

1. Договор и приложение по обработке данных

Первый документ — основной договор на SaaS-сервис. Но его недостаточно. Отдельно запросите DPA или приложение об обработке данных, особенно если вы переносите персональные данные клиентов, сотрудников, подрядчиков или пользователей приложения.

В DPA должны быть указаны:

• категории данных: ФИО, email, телефон, адрес, платежные статусы, документы, IP-адреса;
• цели обработки;
• срок хранения;
• роли сторон;
• список субподрядчиков;
• страны хранения и обработки данных;
• порядок уведомления об инцидентах;
• процедура удаления данных после окончания договора.

Практический ориентир: если в SaaS переносятся клиентские данные, DPA должен быть согласован до первого тестового импорта, а не после оплаты подписки.

2. SLA: доступность, поддержка и ответственность

SLA показывает, насколько поставщик готов отвечать за работоспособность сервиса. В маркетинговой презентации может быть указано «99,9% uptime», но в договоре важно увидеть точные условия.

Проверьте:

• гарантированную доступность: например, 99,5%, 99,9% или 99,95%;
• часы поддержки: 8/5, 12/5, 24/7;
• время первой реакции: например, 1 час для критических инцидентов, 4 часа для средних;
• время восстановления;
• каналы поддержки: тикет, email, чат, телефон;
• компенсации за простой;
• исключения, когда SLA не действует.

Если сервис критичен для продаж, логистики, клиентской поддержки или мобильного приложения, выбирайте вариант с понятным SLA и поддержкой не только «в рабочие дни».

3. Техническая спецификация импорта

Запросите документ, где описано, какие форматы данных принимает сервис и какие ограничения есть у импорта.

В спецификации должны быть:

• поддерживаемые форматы: CSV, XLSX, JSON, XML, API;
• максимальный размер файла;
• лимиты по количеству строк;
• требования к кодировке, например UTF-8;
• обязательные поля;
• допустимые значения;
• правила обработки дублей;
• ограничения по вложениям и файлам;
• описание ошибок импорта.

Пример: если в старой CRM 250 000 контактов, 1,8 млн событий и 40 ГБ вложений, нельзя ограничиться фразой «мы всё перенесем». Нужно заранее понять, что импортируется автоматически, что вручную, а что вообще не поддерживается.

4. Схема маппинга данных

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

Пример маппинга:

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

5. Политика резервного копирования и восстановления

Запросите документ о бэкапах. В нем должны быть указаны RPO и RTO.

• RPO — сколько данных можно потерять между последним бэкапом и сбоем. Например, 15 минут, 1 час, 24 часа.
• RTO — за сколько времени сервис обещает восстановиться. Например, 2 часа, 8 часов, 1 рабочий день.

Что проверить:

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

Если поставщик делает бэкапы раз в сутки, а у вас в системе ежедневно появляется 5 000 новых заказов, риск потери данных может быть неприемлемым.

6. Документы по безопасности

Для SaaS-сервиса важны не только красивые интерфейсы, но и подтвержденные меры защиты.

Запросите:

• политику информационной безопасности;
• описание шифрования данных при передаче и хранении;
• результаты независимого аудита, если есть;
• сертификаты ISO 27001, SOC 2 Type II или аналогичные документы;
• summary по penetration test без раскрытия чувствительных деталей;
• политику управления доступами;
• описание журналов действий пользователей;
• правила MFA/2FA;
• процедуру реагирования на инциденты.

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

7. Порядок экспорта и удаления данных

Перед входом в новый SaaS нужно понимать, как из него выйти. Запросите документ или раздел договора о выгрузке и удалении данных.

Проверьте:

• можно ли выгрузить все данные самостоятельно;
• какие форматы экспорта доступны;
• сохраняются ли связи между объектами;
• выгружаются ли вложения;
• сколько времени доступен экспорт после расторжения;
• когда данные удаляются окончательно;
• выдает ли поставщик подтверждение удаления;
• что происходит с бэкапами после удаления.

Хорошая практика — протестировать экспорт еще до полноценного переноса. Например, загрузить тестовые 500 записей, затем выгрузить их обратно и сравнить структуру.

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

Перед выбором SaaS-поставщика удобно сравнивать не только тарифы, но и зрелость миграционного процесса.

Для небольшого проекта может быть достаточно базового импорта через CSV, если данные не критичны и есть копия в старой системе. Для CRM, ERP, сервис-деска, медицинских, образовательных, финансовых или B2B-платформ лучше выбирать поставщика с формальным планом миграции, SLA и документами по безопасности.

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

Что проверить в смете и техническом задании

Перед оплатой миграции запросите не только тариф SaaS, но и отдельную смету на перенос данных.

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

• объем данных: количество записей, файлов, таблиц, пользователей;
• источник данных: старая CRM, ERP, база SQL, Google Sheets, мобильное приложение, API;
• способ переноса;
• подготовка и очистка данных;
• маппинг;
• тестовый импорт;
• основной импорт;
• проверка результата;
• исправление ошибок;
• гарантийный период;
• стоимость повторной загрузки;
• стоимость доработок.

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

Когда перенос в новый SaaS не подходит

Миграцию лучше отложить или пересмотреть, если:

• поставщик не дает DPA при обработке персональных данных;
• нет понятного способа выгрузить данные обратно;
• импорт поддерживает только часть нужных объектов;
• не переносятся вложения, история действий или пользовательские поля;
• нет тестового контура;
• не описаны бэкапы;
• поддержка отвечает только «по возможности»;
• в SLA нет конкретных сроков реакции;
• стоимость доработок не зафиксирована;
• старый сервис нельзя отключить без потери данных.

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

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

Потеря связей между данными

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

Как снизить риск: заранее согласовать маппинг и проверить выборку из 50–100 записей с разными сценариями.

Дубли и неправильные статусы

Если в старой системе были разные форматы телефонов, email или ID, новый SaaS может создать дубли. Статусы «оплачен», «в работе», «архив» могут перенестись некорректно.

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

Неполный перенос файлов

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

Как снизить риск: отдельно указать в ТЗ объем файлов, допустимые форматы и способ проверки.

Сбой в день переключения

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

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

Скрытая стоимость

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

Как снизить риск: запросить три варианта сметы и письменно зафиксировать, что входит в стоимость.

Чек-лист перед решением

Перед тем как подписывать договор и переносить данные, пройдите короткий чек-лист.

Документы

• Получен договор на SaaS.
• Получен DPA или приложение об обработке данных.
• Есть SLA с понятными сроками реакции.
• Есть политика резервного копирования.
• Есть описание удаления и экспорта данных.
• Есть документы по безопасности.
• Указаны субподрядчики и регионы хранения данных.
• Описан порядок уведомления об инцидентах.

Техническая часть

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

Финансы и сроки

• Получены 3 сметы: базовая, оптимальная и срочная.
• Указаны сроки 3–7 дней или другой реалистичный диапазон.
• Отдельно прописана стоимость переделки.
• Зафиксирована гарантия на результат.
• Понятна стоимость поддержки после запуска.
• Указано, кто оплачивает повторный импорт при ошибке.
• Есть план отката.

Приемка результата

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

Краткий шаблон запроса поставщику

Можно отправить поставщику такой запрос:

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

Дополнительно приложите описание своей системы:

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

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