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

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

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

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

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

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

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

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

| Документ | Зачем нужен | Что проверить |

|---|---:|---|

| DPA / соглашение об обработке данных | Фиксирует роли сторон и правила работы с персональными данными | Кто оператор/обработчик, где хранятся данные, есть ли субподрядчики |

| SLA | Описывает доступность сервиса и реакцию поддержки | Uptime, сроки реакции, компенсации, исключения |

| Техническое описание импорта | Показывает, как именно переносятся данные | Форматы CSV/XLSX/API, ограничения, кодировки, обязательные поля |

| Схема маппинга данных | Помогает сопоставить старые поля с новыми | Что будет с нестандартными полями, тегами, файлами, историей |

| Политика резервного копирования | Нужна для восстановления при ошибке | Частота бэкапов, срок хранения, RPO/RTO |

| Документы по безопасности | Подтверждают зрелость поставщика | ISO 27001, SOC 2, pentest summary, политика доступа |

| Порядок удаления и экспорта данных | Важен при расторжении договора | Срок удаления, формат выгрузки, подтверждение уничтожения |

| План миграции | Фиксирует этапы, сроки и ответственных | Тестовый перенос, окно миграции, откат, приемка |

Какие документы запросить у 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 клиента, история менеджеров, пользовательские теги.

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

| Старое поле | Новое поле | Правило переноса |

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

| client_id | external_id | Переносится без изменений |

| phone_main | phone | Нормализация в международный формат |

| lead_source | source | Значения сопоставляются по справочнику |

| comment_history | notes | Объединяется в хронологию |

| custom_tag | tags | Переносится, если тег есть в новом сервисе |

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

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-поставщика удобно сравнивать не только тарифы, но и зрелость миграционного процесса.

| Критерий | Базовый SaaS | Зрелый SaaS для бизнеса | Enterprise SaaS |

|---|---:|---:|---:|

| Договор | Типовая оферта | Договор + DPA | Индивидуальный договор, DPA, приложения |

| SLA | Может отсутствовать | Есть базовый SLA | Детальный SLA с компенсациями |

| Импорт | CSV/XLSX вручную | Импорт + API + маппинг | Проектная миграция, тестовый контур |

| Безопасность | Общие заявления | Политики, MFA, логи | Аудиты, сертификаты, расширенные отчеты |

| Поддержка | Email, чат | Тикеты, регламенты | Выделенный менеджер, 24/7 |

| Бэкапы | Общая информация | Описаны RPO/RTO | Настраиваемые процедуры восстановления |

| Стоимость внедрения | 0–500 $ | 500–5 000 $ | От 5 000 $ и выше |

Для небольшого проекта может быть достаточно базового импорта через 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-поставщика, чек-лист проверки договора на цифровой сервис и руководство по безопасной выгрузке данных из старой системы.

Можно ли переносить данные без DPA?

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

Достаточно ли обычного CSV-импорта?

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

Какой объем данных проверять на тестовом импорте?

Практичный минимум — 1–5% базы или выборка из разных типов записей: новые, старые, с файлами, с нестандартными полями, с дублями, с разными статусами. Для крупной базы стоит проверять не менее 500–1 000 записей.

Что важнее: SLA или документы по безопасности?

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

Нужно ли оставлять старую систему после переноса?

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

Кто должен делать маппинг данных?

Лучше совместно: ваша команда знает смысл старых полей, а поставщик SaaS понимает структуру новой системы. Итоговый маппинг должен быть согласован письменно до основного импорта.

Что делать, если поставщик не дает документы по безопасности?

Можно запросить краткую версию под NDA. Если поставщик отказывается предоставить даже базовую информацию о шифровании, доступах, бэкапах и инцидентах, перенос критичных данных лучше не начинать.

Какие документы самые важные перед миграцией?

Минимум: договор, DPA, SLA, техническая спецификация импорта, схема маппинга, политика резервного копирования, порядок экспорта и удаления данных, документы по безопасности и план миграции.