Переезд из облачных сервисов на своё
Подписка на облачный офисный пакет удобна, пока компания маленькая. Дальше начинают мешать три вещи: помесячная плата за каждого сотрудника, чужие правила хранения данных и невозможность что-либо настроить под себя.
Что заменяем
| Было в облаке | Становится на своей площадке |
|---|---|
| Почта | почтовый сервер с приёмом, хранением и отправкой, доступ по защищённым протоколам |
| Фильтрация спама у провайдера | отдельный антиспам-шлюз перед почтовиком |
| Видеовстречи | свой сервер конференций без ограничений по длительности и числу участников |
| Диск и документы | файловое хранилище с онлайн-редактором и общими папками |
| Корпоративный чат | свой сервер обмена сообщениями |
Как переносим почту
Самая ответственная часть — почта, потому что терять письма нельзя.
- Свой сервер сначала работает зеркалом облачного — ящики наполняются копией, ничего ещё не переключено.
- Готовим репутацию домена: SPF, DKIM, DMARC, PTR. Заранее снижаем TTL записей, чтобы переключение прошло быстро.
- Разворачиваем направление — свой сервер становится основным, облако остаётся запасным и дозабирает хвосты.
- Живём параллельно две-четыре недели, наблюдая за отчётами о доставке.
- Отказываемся от подписки последним шагом — это точка невозврата.
О чём предупреждаем сразу
Доставляемость исходящей почты — главный риск такого переезда. Попадёт ли письмо в папку «Входящие» у контрагента, зависит от чужих антиспам-систем и лечится неделями прогрева и наблюдением, а не строчкой в конфигурации. Всё остальное здесь — предсказуемая инженерия.
Что получает заказчик
Письма и документы на своих дисках, отсутствие ежемесячной платы за каждого сотрудника и управление доступом через собственный домен.
Если почта и файлы сейчас в Яндекс 360 — отдельная страница «Переезд с Яндекс 360».
Как это выглядело на практике — в кейсе «Инфраструктура разработчика 1С на постоянном обслуживании».
