Миграция с Exchange на Yandex 360: можно ли перенести автоматически

Почта — та система, остановку которой замечают все. Поэтому миграция с Exchange на российскую платформу часто откладывается: страшно потерять переписку, календари, делегирование и привычные клиенты. Вопрос звучит жёстко: можно ли перенести автоматически — или неизбежны недели ручной возни и «день без почты»?

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

Боль здесь двойная. С одной стороны — требования импортозамещения и риски лицензий и поддержки Exchange. С другой — операционный страх: отдел продаж без входящих, бухгалтерия без писем от контрагентов, руководство без календаря встреч. Именно этот страх толкает к наивным схемам вроде «перенаправим MX и разберёмся потом».

На практике срыв почти никогда не выглядит как «платформа не умеет мигрировать». Чаще ломается подготовка: неполный список ящиков, забытые интеграции, DNS «на глаз», отсутствие пилота. Автоматизация усиливает хороший план и ускоряет плохой — поэтому вопрос не в кнопке, а в контуре работ.

Почему наивные схемы ломают переезд

Сценарий «сначала отключим Exchange». Кажется, что так проще контролировать хаос. На деле сотрудники теряют доступ к истории в самый напряжённый момент, а поддержка тонет в тикетах «где мои письма за март». Параллельная работа контуров дороже на старте и дешевле на переключение.

Сценарий «перенесём только inbox». Экономия времени выходит боком: пропадают проектные папки, правила сортировки, общие ящики вида info@, делегирование секретарям. Через неделю выясняется, что «почта работает», но бизнес-процессы — нет.

Сценарий «сделаем вручную через выгрузки файлов». Для десяти ящиков ещё терпимо. Для сотни — это недели рутины, ошибки кодировок, потерянные вложения и невозможность повторить результат одинаково для всех. Ручной путь плохо масштабируется и почти не аудируется.

Типичные грабли миграции почты

• Не инвентаризировали общие ящики, комнаты переговоров и ресурсные календари.
• Забыли про алиасы, цепочки пересылки и правила на стороне сервера.
• Не согласовали DNS заранее: MX, SPF, DKIM, DMARC — письма начинают попадать в спам на следующий день после переключения.
• Не обучили людей новым клиентам и веб интерфейсу — «технически мигрировали», а звонки в поддержку выросли втрое.
• Не зафиксировали критерий готовности: что считаем успешным переносом для VIP-ящиков.
• Не проверили мобильные устройства и сторонние приложения, которые ходят в почту по старым протоколам.

Как выглядит аккуратный автоматический перенос

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

Инвентаризация. Список ящиков, квоты, общие ресурсы, интеграции-(CRM, тикетницы, сканеры, МФУ), мобильные устройства. Без этого «автоматический» перенос упирается в сюрпризы на второй день.

Пилот на 5–15 ящиках. Берут разные роли: руководитель, секретарь с делегированием, общий-sales@, сотрудник с огромным архивом. На пилоте ловят проблемы прав, календарей и клиентов до того, как они ударят по всей компании.

Массовый перенос. Инструменты платформы и миграционные утилиты переносят письма и папки пакетами, с журналированием ошибок. Важно уметь догружать «хвост» — то, что появилось в Exchange после первого прохода. Именно догрузка отличает аккуратный переключение от «почти всё перенесли».

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

Гигиена после. Мобильные профили, подписи, правила, доступ к общим ящикам, мониторинг очередей и жалоб на спам. Миграция заканчивается не в момент смены MX, а когда тишина в поддержке становится нормой.

Если переезд связан с импортозамещением и требованиями к размещению в РФ, удобно опираться на практику корпоративной почты Yandex 360 — с упором на сохранение непрерывности, а не на «галочку в отчёте».

Что автоматизировать, а что оставить людям

Автоматизируют создание учёток, перенос писем, календарей и контактов, повторные догрузки, отчёты «сколько перенесено-/-сколько ошибок». Людям оставляют решения: какие архивы реально нужны, кого мигрировать в первую волну, как назвать общие ящики, какие интеграции отключить на время переключение.

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

Итог для бизнеса: почта без драмы

Успешная миграция с Exchange измеряется не слайдом «переехали», а тремя вещами: входящие не пропадали, история на месте у ключевых сотрудников, через две недели поддержка не тонет в «куда делись письма». Автоматический перенос как раз про повторяемость и контроль, а не про обещание нулевого участия заказчика.

Для руководителя практичный критерий готовности простой: есть пилот с подтверждением «всё нужное на месте», есть план DNS и откат на бумаге, есть список VIP-ящиков с персональной проверкой. Если этого нет — рано переключать MX, какой бы ни был инструмент.

Импортозамещение почты неизбежно поднимает эмоции. Спокойный сценарий выглядит так: инвентаризация → пилот → волны → короткий переключение → пост-контроль. Тогда вопрос «можно ли автоматически» перестаёт быть маркетинговым и становится инженерным: основную массу — да; хаос и простой — нет, если готовиться.

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