Exchange на исходе поддержки: что делать бизнесу

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

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

Главная ошибка — делать вид, что «пока открывается, можно не решать». Край поддержки — это календарная точка риска, а не сюрприз.

Чем опасен Exchange «за чертой»

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

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

Аудит и страхование. Формулировка «ПО без поддержки» плохо выглядит в любом серьёзном опроснике. Иногда вопрос задаёт не злодей, а ваш же клиент из enterprise-сегмента.

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

Скрытый простой. Чем старше контур, тем страшнее любое изменение — и тем дольше живут временные «не трогать». Это тоже форма деградации сервиса.

Как компании дотягивают до края

Почту не трогают из страха: «переезд ящиков — это боль». Боль откладывают, пока она не становится неизбежной. Неизбежность всегда дороже планового проекта.

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

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

Ошибки на развилке

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

Менять всё сразу: и почту, и файлы, и доменные политики в одном окне. Так трудно откатываться и ещё труднее понять причину сбоя.

Оценивать только лицензию облака против «у нас сервер уже куплен», забывая про труд админов, бэкапы, аварийное восстановление и простой. Купленный сервер не равен дешёвой эксплуатации.

Не учитывать телефонию и CRM интеграции, которые завязаны на календари и ящики. Почта редко живёт одна.

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

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

Практичные ветки решения

Если Exchange остаётся стратегией — планируют миграцию на поддерживаемую версию с обновлением ОС, ролей, сертификатов и схемы гибрида при необходимости. Это проект с инвентаризацией, пилотом и окном переноса, а не «ночное обновление».

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

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

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

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

Переходный период без самообмана

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

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

Критерии выбора между миграцией и заменой

Оставляйте Exchange стек, если у вас сильная внутренняя экспертиза, специфические интеграции и понятная стоимость владения на горизонте нескольких лет. Смотрите в сторону замены сервисом, если команда тонкая, аудит давит, а ценность именно в доставке почты и календаря, а не в владении сервером.

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

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

Итог

Exchange на исходе поддержки — не повод для паники в пятницу и не повод для вечного отрицания. Это управляемый риск с календарём. Чем раньше появится план — миграция или замена — и пилот, тем дешевле выйдете.

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

Разобрать текущий Windows/Exchange контур и спроектировать переход можно в рамках направления Windows Server — с инвентаризацией, вариантами целевой схемы и аккуратным переносом, а не с лозунгом «надо срочно в облако».