Глобальная стратегия Atlassian по переходу в облако делает миграцию из этой экосистемы все более актуальной задачей для российских компаний. Рассмотрим, как при переходе сохранить бизнес-логику, минимизировать риски и правильно организовать процесс.
Почему пришло время мигрировать c Atlassian
Решениями Atlassian еще пользуются в российских компаниях, но все больше факторов подталкивают бизнес к переходу на альтернативные платформы. 15 февраля 2024 года вендор прекратил официальную поддержку, выпуск обновлений и исправлений для продуктов линейки Server. Формально эти системы можно продолжать использовать в закрытом контуре, принимая на себя риски.
30 марта 2026 года закрылись продажи продуктов линейки Data Center новым клиентам, а с 30 марта 2028 года обладатели действующих подписок не смогут покупать новые лицензии, расширения и приложения из Atlassian Marketplace. 28 марта 2029 года жизненный цикл локальных решений окончательно подойдет к концу: сроки действия подписок Data Center завершатся, а системы, связанные с приложениями из Marketplace, перейдут в режим только для чтения.
На смену этим решениям в экосистеме вендора приходит линейка Cloud. Это часть стратегии перевода в облако, которую Atlassian последовательно реализует уже несколько лет. Однако российскому бизнесу Cloud подходит не на 100%, поскольку не в полной мере отвечает требованиям информационной безопасности, не поддерживает работу в закрытом контуре и сложную кастомизацию. К тому же многие отечественные компании не могут выносить данные в зарубежный облачный сервис.
В этих условиях раннее планирование миграции с Atlassian выглядит оптимальным вариантом. Оно позволит избежать рисков, связанных с продолжением эксплуатации устаревших продуктов без официальной поддержки.
Во-первых, даже закрытый контур не делает систему «бессмертной». Чем дольше она работает без обновлений безопасности, тем выше становятся накопленные риски. Во-вторых, по мере модернизации остальной ИТ-инфраструктуры может ухудшаться ее совместимость с лишенными поддержки решениями Atlassian. В-третьих, через два-три года может быть сложнее найти сотрудников, хорошо знакомых со старой версией системы, старыми плагинами и кастомизациями. В-четвертых, бизнес-процессы постепенно перестраиваются, а вместе с ними должна дорабатываться платформа. Такие изменения лучше вносить сразу в новую систему, чем в старую, от которой вероятно придется отказаться.
Что перенести на новую платформу
При миграции с Atlassian в первую очередь следует перенести управление задачами, проектами и статусами, а главное — жизненными циклами, ведь именно на них опираются реальные бизнес-процессы. Важно переместить не просто карточки, а соответствующие им операции, иначе система не будет работать и превратится в обычный архив.
Второй слой миграции — структура данных: настраиваемые поля и схемы распределения прав доступа. Они кажутся незначительными элементами, но именно на их основе строятся отчетность, маршрутизация, фильтры и SLA (соглашения об уровне услуг). Главное — не копировать все поля и права без изменений, а заново собрать модель таким образом, чтобы она была безопасной и актуальной.
Третий слой — аналитика: дашборды, отчеты и настроенные фильтры. Основная ценность системы для руководителей часто заключается не в управлении задачами, а именно в этих инструментах. Без них даже переход на более мощную платформу может вызвать негативную реакцию менеджмента. В связи с этим следует тщательно продумать перенос аналитики и заранее включить его в план проекта.
Четвертый слой — базы знаний из Confluence и сопутствующие вложения из Jira. При миграции важно оценить, какие из них лучше перенести в активный контур, какие — архивировать, а какие — удалить. Переход на новую платформу станет удачным моментом для такой оптимизации.
Следующий слой — экосистема: внешние интеграции и установленные плагины, которых в крупной компании может накопиться очень много. Для их правильного переноса следует перед миграцией составить архитектурную схему, на которой будет указано, какие интеграции и плагины используются, зачем они нужны и насколько они критичны для бизнеса. Это поможет спланировать, что предстоит актуализировать, что — собрать заново, а что — заменить.
Пошаговый план миграции
Чтобы переход на новую платформу прошел успешно, важно использовать системный подход к подготовке и осуществлению миграции. Эту работу можно разделить на шесть шагов.
Шаг 1. Инвентаризация данных и аудит процессов. Сначала необходимо проанализировать набор используемых продуктов Atlassian, проверить их версии и сроки окончания поддержки. Следует оценить связанные с платформой риски на горизонте двух-трех лет, а также определить, требуется ли ее дорабатывать в ближайшее время. Работа в условиях закрытого контура не снимает вопросы технической поддержки, информационной безопасности, обновлений, совместимости и планирования выхода из экосистемы — их все равно нужно прояснить заранее. Также следует составить карту процессов, разделяя их по сценариям и выделяя критически важные для бизнеса операции. Это поможет сделать обоснованный выбор, на какую систему или гибридное решение переходить. Главным критерием должна стать возможность воспроизвести текущие процессы на новой платформе.
Шаг 2. Проектирование целевой модели в новой системе. После инвентаризации следует спроектировать целевую модель с описанием того, как процессы будут функционировать после перехода. Необходимо определить, какие операции перейдут в новую систему, что произойдет с архивом, где потребуются интеграции и как они будут работать, а также каким образом будет организован переход пользователей. Отдельного внимания требуют правила переноса исторических данных и нефункциональные требования. Необходимо описать, как должна работать система, задать требования к отказоустойчивости и информационной безопасности.
Шаг 3. Первичная настройка и кастомизация платформы. На этом этапе нужно настроить выбранную платформу или связку платформ: создать процессы, формы, роли и другие элементы, необходимые для работы решений, а также настроить права доступа, аналитику, уведомления, интеграции и маршруты согласования — все то, что обеспечивает функционирование ПО в рамках реальных рабочих процессов. Важно не стремиться к точному копированию старой системы, иначе есть риск перенести накопившиеся в ней проблемы в новый интерфейс; устаревшие процессы целесообразно собрать заново, проведя их аудит и оптимизацию.
Шаг 4. Тестовый перенос ограниченного объема данных. В его рамках следует проверить, как в новую систему перемещаются задачи, поля, статусы и другие элементы. Особое внимание стоит уделить тому, что не перенеслось автоматически: как правило эта информация наиболее полезна для доработки процесса. В автоматическом режиме обычно переносятся задачи, описания и другие элементы, поддающиеся прямому сопоставлению. Однако корректность такого переноса напрямую зависит от точности карты соответствия полей между системами, особенно если платформы различаются по структуре данных. При этом важно четко определить назначение каждого элемента: без правильной интерпретации значений старых полей и статусов автоматизированный перенос данных может пройти некорректно. По итогам этого шага необходимо проанализировать миграционный отчет, однако не менее важна сама практика тестового переноса.
Шаг 5. Проверка реальных пользовательских сценариев. На этом этапе в первую очередь тестируют пользовательский опыт: насколько удобно создавать заявки, согласовывать их и назначать исполнителей, работают ли переназначение по процессу, SLA и аналитика, закрываются ли обращения и насколько удовлетворены пользователи. Если все эти сценарии выполняются корректно, миграция становится не просто технически успешной, но и полезной для бизнеса.
Шаг 6. Итоговая промышленная миграция. Финальный этап — промышленная миграция, сопровождаемая волнами коммуникации с командами. Она должна стать не резким отключением старой системы, а плавным управляемым переходом, о котором заранее знают все участники и в рамках которого четко определены роли и зоны ответственности. Это исключает ситуации, в которых сотрудники месяцами дублируют работу в двух системах одновременно, и позволяет сервисным менеджерам бесшовно перейти на новую платформу.
Основные риски миграции
Если неправильно спланировать переход на новую платформу, можно нарушить уникальную бизнес-логику, зафиксированную в глубоких кастомизациях решений Atlassian. Это более серьезный риск, чем потерять данные. Даже если успешно перенести все задачи, комментарии и вложения, но упустить из виду правила согласования или автоматическое переназначение, бизнес-процесс не будет работать.
Другой важный риск — сложности и ошибки при переносе исторических данных. Если таких записей накопилось много, перемещать весь массив может быть дорого, долго и нецелесообразно. Однако вовсе не перенести исторические данные — опасно для бизнеса. Разумным выбором станет категоризация элементов с учетом ценности и применения в рабочих процессах.
Третий риск при миграции — неполный или некорректный перенос прав доступа и ролевых моделей. Следует отдельно планировать распределение прав на новой платформе: если они выйдут за нужные рамки, возникнут проблемы безопасности, а если слишком сильно ограничить доступ, пользователи не смогут нормально работать. Это особенно критично для сервисных процессов, HR-заявок, защиты данных, финансовых согласований, проектной документации и базы знаний.
Четвертый риск — жесткая зависимость от приложений из Marketplace, у которых нет прямых аналогов. На старых версиях Atlassian одни и те же плагины могли работать годами. В таких случаях при миграции возникают вопросы, какую логику они используют, кто ее поддерживает, можно ли отказаться от этих приложений и есть ли у них аналоги. Иногда небольшой плагин оказывается самым критичным элементом всего бизнес-процесса, поэтому миграцию надо начинать с аудита, а не с выбора новой платформы.
Наконец, главная ошибка — попытка перенести систему как есть, без предварительной оптимизации. При таком подходе вместе с полезными составляющими можно скопировать источники хаоса. Задача миграции не сохранить все плюсы и минусы старой системы, а обеспечить корректную работу процессов, убрать лишнее и выстроить эффективную архитектуру.
Безопасный переход
Сделать миграцию максимально комфортной и безопасной поможет в первую очередь отказ от переноса всех составляющих старой системы. Активные элементы можно добавить в рабочий контур, важные исторические данные — сохранить в архиве, а ненужные записи — удалить. Еще одним обязательным условием успеха станет тестовый перенос. Пилотная часть проекта поможет проверить критически важные узлы архитектуры и оценить реальную картину.
Для компании, которая рассматривает миграцию с Atlassian, на первом плане должен быть не вопрос, работает ли платформа сегодня, а возможность безопасно выстраивать процессы на ее базе в перспективе. Если слишком долго откладывать переход на новую систему, можно оказаться в ситуации, когда поддерживать старые решения слишком дорого, а отказаться от них слишком сложно. В связи с этим лучше заранее выстроить на основе отечественного ПО новую жизнеспособную архитектуру, которая будет получать официальную поддержку и эволюционировать вместе с бизнес-процессами компании.
