Переезд с зарубежного SaaS ломается не на названии нового продукта. Он ломается на списке данных, правах доступа, форматах экспорта и моменте, когда бизнес просит показать, что прежние рабочие сценарии действительно перенесены.
Поэтому первый документ проекта — не сравнительная таблица брендов. Это карта сервисов: почта, календарь, файлы, чаты, формы, задачи, учетные записи, архивы и интеграции. Для каждого блока нужен владелец, формат выгрузки, способ проверки после импорта и решение, что делать с данными, которые нельзя перенести автоматически.
Google Workspace Data Export, проверенный 23 мая 2026 года, показывает хороший пример такого подхода. Экспорт запускается из учетной записи super administrator. В настройке выбирают scope, Service box и Date range & type. Для Google Drive, Gmail и Chat можно выбирать диапазон дат или continuous exports, но shared drive files cannot be filtered by time range. Эта строка превращается в практическое требование: общие диски надо проверять отдельным сценарием, а не одной галочкой в плане.
Microsoft Purview, проверенный 23 мая 2026 года, дает другой набор границ. В eDiscovery Standard после поиска можно экспортировать результаты: mailbox items скачиваются в PST files или individual messages, а SharePoint и OneDrive отдают копии native Office documents и других документов. В том же описании есть deduplication option, чтобы при совпадениях выгружалась одна копия email message. Это полезно для архива и юридической сверки, но не означает готовый перенос Teams-логики, прав на файлы, правил согласования или пользовательских привычек.
Отсюда появляется рабочая формула миграции. Каждый SaaS-блок получает свой результат приемки: письмо найдено в новом ящике, календарь открывается нужной группе, файл сохранил владельца, ссылка не раскрыла лишний доступ, интеграция с CRM снова создает задачу, архив читается ответственным сотрудником. Если такого результата нет, экспорт считается технической выгрузкой, а не завершенным переездом.
На стороне российского сервиса тоже нужны конкретные gates. В инструкции Яндекс 360 для миграции с другого сервера CSV-файл содержит адрес и пароль исходного ящика, а также логин учетной записи на домене, куда импортируются письма. Там же указано: можно добавить до 20,000 usernames, файл надо сохранить в UTF-8, а перед повторными миграциями стоит сохранять лог. Для проекта это означает три проверки: кто собирает исходные доступы, как защищается CSV, кто сверяет журнал ошибок после каждой попытки.
VK WorkSpace на официальной странице разделяет размещение в облаке по модели SaaS и размещение в контуре компании. Там же сказано, что перенос корпоративной почты с Gmail, Microsoft Exchange, Outlook или Яндекс 360 делается по инструкции, а оплата возможна картой или по счету через личный кабинет. Эти строки не заменяют договор и техническое задание, но задают вопросы до пилота: нужен ли облачный вариант, нужен ли контур компании, кто получает закрывающие документы, как оформляется владелец организации.
Юридические и закупочные статусы нельзя брать из рекламного блока. Если для закупки нужен реестр российского ПО, карточка проверяется в официальном реестре на дату решения. На 23 мая 2026 года корректная формулировка для проекта такая: реестр является обязательным местом проверки, а не аргументом из памяти или пересказа поставщика.
Пилот стоит строить на реальных ролях, а не на демонстрационной группе. Минимальный набор: один руководитель, один сотрудник с большим архивом, один пользователь общих дисков, один участник внешней переписки, один администратор интеграций. Для каждого фиксируются исходный сервис, новый сервис, способ экспорта, способ импорта, что проверяется вручную и какой откат допустим.
Отдельный слой — права доступа. В старом SaaS часто годами накапливаются внешние ссылки, гостевые аккаунты, наследованные группы и личные владения файлами. Если их просто перенести, новый сервис наследует старый беспорядок. Если их обнулить, бизнес потеряет рабочие цепочки. Поэтому права лучше переносить через матрицу ролей: владелец, редактор, читатель, внешний участник, администратор.
Финальный переход имеет смысл запускать только после трех отчетов. Первый — инвентаризация данных и исключений. Второй — протокол пилота с ошибками и решением по каждой ошибке. Третий — план дня переключения: стоп изменений в старом сервисе, финальная выгрузка, импорт, проверка, открытие доступа, окно отката.
Название продукта появляется ближе к концу. До этого проверяются данные, роли, документы, платежи, журнал миграции и приемка. Такой порядок не делает проект проще, зато быстро показывает, где переход реален, где нужен ручной перенос, а где старый SaaS пока остается архивным источником.
Источник обложки: https://commons.wikimedia.org/wiki/File:Business_professional_engages_in_note-taking_during_a_meeting_at_a_modern_office_desk.jpg
Читайте также: