Atlassian официально сворачивает линейку Data Center и в несколько этапов переводит клиентов в облако. С 30 марта 2026 года новые клиенты больше не смогут купить Data Center; с 30 марта 2028 года эта возможность исчезнет и для существующих клиентов; 28 марта 2029 года все инстансы и маркетплейс-плагины станут read-only. Это не «слухи», а подтверждённый график на сайте Atlassian. (atlassian.com)
Для российских компаний это удар сразу по трём точкам: безопасность (нет обновлений), процессная устойчивость (застывают плагины и интеграции) и юридические риски (локализация и 152-ФЗ). Иллюзия «пересидим до 2029-го» опасна: перенос историй задач, вложений и кастомных workflow ближе к дедлайну станет дороже и дольше. Рынок это тоже признаёт: останавливается on-prem-ветка, и «окно» для комфортной миграции сжимается уже с 2026 года. (atlassian.com)
Что важно понимать прямо сейчас
-
Режим read-only — это фактическая остановка работы, а не «мелкое неудобство»: вы не сможете вести спринты, создавать страницы знаний, обновлять плагины, а закрытие уязвимостей окажется на вашей совести. Так написано в официальной политике EOL. (atlassian.com)
-
Облако Atlassian подходит не всем: для многих отраслей данные должны храниться в РФ, да и санкционные риски никто не отменял. Российские источники также фиксируют курс Atlassian на Cloud-first и поэтапный отказ от серверной модели. (Habr)
-
Чем позже — тем дороже: к 2026–2028 годам начнутся очереди к интеграторам и дефицит компетенций. Atlassian прямо указывает ключевые срезы времени — их и используйте для планирования. (atlassian.com)
Три стратегии замены (с фокусом на импортонезависимость)
1) Полный переход на self-hosted / open-source стек (рекомендовано для SMB)
Цель: сохранить контроль над данными, снизить TCO и избежать vendor lock-in. Типовая конфигурация Progressive OS:
- Проектное управление / разработка: OpenProject или Redmine; Git-хостинг — Gitea/Forgejo.
- Service Desk: Zammad или GLPI (каталоги услуг, SLA, почта/телефония).
- Знания/документация: Wiki.js или XWiki (импорт из Confluence).
- Совместная работа: Nextcloud (+ Talk, Deck, Collabora).
- Коммуникации: Asterisk, Matrix/Mattermost.
- Интеграции и автоматизация: n8n + вебхуки (Git/SD/PM), SSO/LDAP/2FA.
Когда выбирать: нужна локализация, офлайн-устойчивость и гибкость процессов; облако юридически/репутационно неприемлемо.
2) Гибрид (временный мост)
Часть функций держим локально (код, CI/CD), а часть переносим в совместимое облако. Подходит как «лестница» для команд с жёсткими требованиями по сегментации и несколькими потоками миграции. Важный риск — вы управляете сразу двумя мирами, это требует зрелого ИТ-контроля.
3) Облако Atlassian или SaaS-аналоги
Если облако допустимо юридически и по ИБ, этот путь обеспечивает скорость запуска, но требует трезвой оценки данных и интеграций. Ключевые даты всё равно «тикают» — их игнорировать нельзя. (atlassian.com)
Российские «коробочные» альтернативы (self-hosted, проприетарные)
- EvaTeam (EvaProject, EvaWiki, EvaServiceDesk) — заявляет функциональную замену Jira/Confluence/JSM, включая аналоги популярных плагинов (ScriptRunner, Tempo, eazyBI, Structure; draw.io, PlantUML и др.). Позиционируется как «российский конвейер разработки» и «замена Atlassian». Используется на рынке и активно комментирует EOL Atlassian на Хабре. (EvaTeam)
- Kaiten — «российский аналог Jira и Confluence», доступен как в облаке, так и в коробке; входит в Единый реестр российского ПО, заявляет импорт из Jira «в несколько кликов», фокус на Scrum/Kanban. Есть подробные сравнения и обзоры. (Kaiten)
Наша позиция проста: в SMB мы рекомендуем начинать с self-hosted (open-source или «коробки») и только затем при необходимости наращивать облако — так вы сохраняете контроль и снижаете риски.
Дорожная карта миграции (6 шагов «без боли»)
1) Инвентаризация. Фиксируем версии Jira/Confluence/JSM, список плагинов и их критичность, объёмы задач/страниц/вложений, интеграции (CI/CD, LDAP, почта), отчёты и SLA, кастомные workflow. 2) Целевой дизайн. Выбираем стек, согласуем требования ИБ (152-ФЗ, сегментация, шифрование, журналирование), настраиваем роли/права. 3) Пилот (PoC). Разворачиваем тестовый контур, добиваемся паритета ключевых сценариев: схемы проектов, поля/статусы, шаблоны заявок, структура базы знаний; готовим маппинг сущностей (Issue → WorkPackage, Space → раздел Wiki). 4) Перенос данных. Экспорт/импорт задач, комментариев, вложений, аккаунтов. Для Confluence — XML/HTML-экспорт и конвертация в XWiki/Wiki.js; для Jira — выгрузки/скрипты с сохранением ключей и истории. 5) Интеграции и автоматизация. Почта, телефония, вебхуки, уведомления, отчёты руководству; n8n/Flow для рутины. 6) Обучение и запуск. Короткие регламенты и видео-гайды, «горячая линия» на первые 2–4 недели; контроль метрик адаптации (скорость спринтов, закрытие заявок, удовлетворённость пользователей).
Тайминг: когда начинать
- Сентябрь 2025 — март 2026: оценка и пилот, пока ещё есть время на вдумчивый выбор.
- С апреля 2026: для новых клиентов продажи Data Center закрыты — «узкие места» начнутся в полный рост.
- 2026–2028: основная волна миграций у рынка; в конце периода спрос на интеграторов будет максимальным.
- 28 марта 2029: EOL и read-only — точка невозврата, подтверждённая Atlassian. (atlassian.com)
Как мы делаем такие проекты в Progressive OS
- Импортонезависимый стек (open-source и/или «коробки»), который реально поддерживать в РФ.
- Локально и безопасно: хранение у клиента, 2FA, шифрование, резервное копирование, аудит.
- Миграция «с руками»: скрипты, маппинг полей/статусов, перенос вложений и страниц знаний без потерь.
- AI-ускорители: генерация регламентов и шаблонов, суммаризация страниц, «умный» поиск по базе знаний.
- Метрики ценности: SLA, MTTR, скорость спринтов, NPS — рост эффективности за счёт снижения человеко-часов, а не качества.
FAQ руководителя (коротко)
Можно «пересидеть» до 2029? Теоретически да, но инстанс станет read-only, а плагины — «замороженными». Это официально прописано и означает фактическую остановку развития и повышенные риски ИБ. (atlassian.com)
Bitbucket можно оставить on-prem? Atlassian в своём анонсе выделяет исключения/переходные режимы по продуктам, но общий вектор — EOL Data Center к марту 2029. Точный сценарий зависит от вашей текущей лицензии и дорожной карты; «оставить как есть» после EOL нельзя. (atlassian.com)
Сколько длится проект? Типовой SMB-контур (Jira + Confluence + JSM): пилот 2–6 недель, миграция 1,5–3 месяца в зависимости от объёмов и интеграций. Важно закладывать время на обучение.
Ссылки на источники:
- Официальная страница Data Center End of Life с датами 2026/2028/2029 и режимом read-only: сайт Atlassian. (atlassian.com)
- Блог Atlassian с анонсом Ascend to the cloud и поэтапным графиком: март-2026 (новые клиенты), март-2028 (существующие), март-2029 (EOL): сайт Atlassian. (atlassian.com)
- Подтверждение про read-only и окончание действия подписок/плагинов в 2029: страница лицензирования Data Center: сайт Atlassian. (atlassian.com)
- Российский контекст и последствия для рынка: публикации EvaTeam на Хабре. (Habr)
- Российские альтернативы: EvaTeam (EvaProject/EvaWiki/EvaServiceDesk) — официальный сайт; Kaiten — сравнение с Jira, наличие коробочной версии и импорта. (EvaTeam)
Окно для спокойной, управляемой миграции — сейчас. Выберите целевой стек (open-source/«коробка»/гибрид), поднимите пилот, утвердите паритет процессов и перенос данных — и только потом переносите команды и отчётность. Мы готовы провести аудит, спроектировать целевой контур и выполнить миграцию «под ключ».