Как отказаться от SaaS и перенести данные без остановки работы

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

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

Опишите, что именно должно переехать

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

Рядом перечислите то, что не хранится в основных записях:

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

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

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

Выберите новое место и сопоставьте поля

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

Особенно внимательно проверьте идентификаторы и связи. Номер задачи 125 может совпасть с уже существующим номером в новой системе. Ссылка из комментария на старую запись после импорта может вести в пустоту. Пользователь с тем же адресом может иметь другую роль.

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

Проведите пробу на небольшом наборе

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

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

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

Назначьте момент окончательного переключения

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

Заранее сообщите:

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

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

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

Переключите людей и интеграции

Создайте персональные аккаунты и роли в новой системе, включите 2FA администраторам и проверьте восстановление. Не копируйте старые общие пароли. Порядок настройки разобран в статье о доступах SaaS.

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

В течение контрольного периода собирайте конкретные ошибки: какая запись, какое действие, кто проверял и чем ожидание отличается от результата. Общая фраза «что-то не перенеслось» не помогает восстановить данные.

Закройте старый сервис без потери последней копии

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

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

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