Как перенести календари 200 сотрудников в Yandex 360

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

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

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

Что именно нельзя потерять

Личные события сотрудников — только часть картины. Для офиса критичны переговорные: если комнаты не переедут как ресурсы с расписанием, люди начнут бронировать «на словах» в чате. Это быстро возвращает хаос, от которого как раз уходили.

Дальше — делегирование. Секретарь видит календарь руководителя, ассистент ставит встречи от чужого имени, руководитель отдела смотрит загрузку команды. Если права не перенести, в первый же понедельник полетят жалобы: «я не вижу слоты», «мне нельзя создать событие».

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

Почему «выгрузите ICS» не работает на 200 человек

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

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

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

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

Типичные промахи миграции календарей

Откладывать календари «на потом», после почты. Потом оказывается, что «потом» — это уже переключение weekend, и времени на аккуратный перенос нет.

Переносить только личные календари, забыв про ресурсы переговорных и общие календари отделов.

Не зафиксировать матрицу делегирования до старта. Восстанавливать её по памяти руководителей после переезда — отдельный мини проект в пожарном режиме.

Делать большого взрыва без пилота. Имеет смысл сначала прогнать 10–20 человек из разных ролей: руководитель, ассистент, сотрудник без прав, администратор переговорных.

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

Рабочий подход без ручного героизма

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

Затем выбор механизма массового переноса: автоматизация через API/сервис миграции платформы, а не ручной ICS. Задача инженера — проверить полноту прав, серий и ресурсов, а не кликать «экспорт» двести раз.

Параллельно — правила переходного периода. Обычно фиксируют дату, после которой новые встречи создают уже в Yandex 360, а старый контур на короткое время остаётся read-only или используется только для сверки.

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

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

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

Что проверить за две недели до переключение

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

Выборка руководителей с плотным календарём: если у них после переноса дыры в сетке, поддержка утонет в приоритетных заявках.

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

Внешние приглашения. Если часть встреч с контрагентами, проверьте, как выглядит письмо приглашение после переезда и не ломается ли цепочка ответов.

И наконец — критерии «готово»: не процент выгруженных ICS, а рабочие сценарии из пилота, повторённые на боевой выборке.

Кто должен участвовать со стороны бизнеса

Миграция календарей кажется «чисто IT-шной», но без офис менеджера или владельца переговорных вы обязательно потеряете ресурсы комнат. Без помощников руководителей не соберёте матрицу делегирования. Без коммуникаций HR или внутренних коммуникаций люди в день X будут писать в случайные чаты.

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

Какой результат считает бизнес успешным

Успех миграции календарей — это не красивый отчёт «200/200 перенесено». Это первая рабочая неделя без шторма в поддержке. Переговорные бронируются. Руководители видят сетку. Ассистенты ставят встречи. Повторяющиеся события на месте. Люди не возвращаются в старую систему «на всякий случай».

Для IT успех — воспроизводимый процесс и документированные исключения: что не переехало автоматически и почему, кто это закрыл вручную, где лежат права доступа.

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

О формате работ по корпоративной почте и сопутствующим сервисам можно посмотреть в разделе Корпоративная почта Yandex 360 — там же обычно собирают и календарную часть переезда, чтобы не чинить её отдельно через месяц.