Как переехать с Google Workspace или Microsoft 365 на собственную корпоративную платформу

Отказ от Google Workspace или Microsoft 365 затрагивает не только почту и документы. Компания переносит учётные записи, права, календари, адресные книги, правила и интеграции, поэтому копирования недостаточно. Например, облачное хранилище Nextcloud от Maxiplace может стать файловым компонентом новой среды, но почту, идентификацию и интеграции нужно проектировать отдельно.

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

Google Workspace и Microsoft 365 объединяют несколько функций учётной записью. Сотрудник получает письма, открывает общие папки, назначает встречи, входит в CRM через Google или Microsoft и использует правила. При переносе только писем или файлов эти связи исчезают.

Скрытый риск — ящик, куда сайт отправляет заявки, а CRM забирает их. Если не перенастроить отправителя, получателя, SMTP или обработчик, обращения могут остаться на старой стороне. Поэтому единицей миграции должен быть рабочий сценарий, а не отдельный файл.

Составьте реестр объектов:

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

«Собственная платформа» не обязательно означает сервер в офисе. Это может быть частное или управляемое облако, но компания должна определить компоненты, администраторов, резервное копирование, обновления, мониторинг, восстановление и поддержку.

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

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

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

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

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

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

Для каждой интеграции проведите тест: заявка с сайта должна дойти до нового ящика и появиться в CRM; приглашение — попасть участнику; уведомление — уйти с разрешённого домена. Проверяйте результат, а не только успешное соединение.

MX направляет входящую почту на новый сервер. SPF перечисляет разрешённые источники отправки, DKIM добавляет проверяемую подпись, а DMARC задаёт политику для писем, прошедших или не прошедших согласование домена. Эти записи не взаимозаменяемы.

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

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

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

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