Прежде чем переезжать в Jira Cloud: 10 проверок для клиентов Data Center в Казахстане

Прежде чем переезжать с Jira Data Center в Jira Cloud, команде в Казахстане нужно ответить на десять вопросов. Готова ли компания держать данные трекера за рубежом. В каком регионе они окажутся. Сколько облако будет стоить за три года. Что станет с приложениями, скриптами, правами и интеграциями. Упрётся ли миграция в лимиты. Как откатиться. И не выгоднее ли остаться на своём сервере, сменив трекер. Если хотя бы на три вопроса ответа нет, назначать дату переезда рано.

Статья для руководителей IT, администраторов Jira и тимлидов в компаниях, которые работают на Data Center. Внутри: сроки, которые задаёт Atlassian, десять проверок с порядком действий, расчёт стоимости для 100 пользователей и сводная таблица «проверка → как проверить → что делать при провале», которую можно забрать в план миграции.

Сроки Data Center: почему решение нельзя откладывать

Atlassian зафиксировала график. Его стоит держать перед глазами, когда вы планируете бюджет и загрузку команды.

Дата	Что происходит
15 февраля 2024	Закончилась поддержка Jira Server
30 марта 2026	Прекращены продажи новых лицензий Data Center
30 марта 2028	По данным партнёров Atlassian, последний срок продлений и расширений для действующих клиентов
28 марта 2029	Конец поддержки Data Center: лицензия только на чтение, Marketplace-приложения перестают работать

Практический вывод простой. Спокойная миграция возможна, пока у вас действует продление и есть запас времени на ошибки. Если тестирование придётся на последний год, любая проблема с приложениями или правами превращается в аварию. Сценарии ухода с Data Center мы подробно разбирали в статье Jira Data Center закрывается в 2029 году. Здесь только то, что нужно проверить до решения о переезде в облако.

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

Проверки 1–2: персональные данные и регион хранения

1. Есть ли в Jira персональные данные

Таск-трекер кажется техническим инструментом, но персональные данные в нём есть почти всегда. Имена и рабочие почты сотрудников. Обращения клиентов с телефонами. Скриншоты из CRM во вложениях. Выгрузки для отладки. Резюме кандидатов в задачах HR.

До переезда компании нужно решить, готова ли она хранить такие данные за пределами Казахстана. Часть заказчиков и партнёров просит хранить данные в стране, и это тоже стоит учесть.

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

2. Какой регион хранения вы получите

В Atlassian Cloud есть data residency: данные продукта можно закрепить за регионом. В списке США, ЕС, Германия, Великобритания, Швейцария, Австралия, Сингапур, Япония, Индия, Южная Корея и Канада. Казахстана нет.

Выбор региона определяет, в какой стране будут лежать данные, но не делает их казахстанскими. Если чувствительных данных в трекере нет или их можно вычистить, регион выбирают по задержкам и пожеланиям партнёров. Если данные важно хранить в Казахстане, облако не подходит независимо от цены и функций. Отдельно уточните в документации Atlassian, какие именно данные и на каком тарифе закрепляются за регионом.

Контекст Казахстана. Jira Cloud оплачивается корпоративной картой в долларах, а закрывающих документов по казахстанским стандартам вендор не выдаёт. Бухгалтерию стоит подключить к проверке до решения, а не после первого счёта. Русский интерфейс в Jira встроен. Если часть пользователей работает через казахский языковой пакет из Atlassian Marketplace, проверьте его доступность для облака отдельно. Партнёры Atlassian в Казахстане есть, например Teamlead со статусом Gold Solution Partner, и с ними можно обсудить лицензии и миграцию.

Проверка 3: стоимость на три года

Облако сравнивают не с текущим продлением, а с полной стоимостью владения за три года. В Data Center часть расходов скрыта в инфраструктуре и работе администратора. В облаке они превращаются в подписку за каждого пользователя.

Расчёт для 100 пользователей по прайсу Atlassian на октябрь 2026 года при годовой оплате:

Набор	За пользователя в месяц	В год	За три года
Jira Standard	$7,91	$9 492	$28 476
Jira Premium	$14,54	$17 448	$52 344
Confluence Standard	$5,42	$6 504	$19 512
Atlassian Guard Standard	$4,20	$5 040	$15 120
Jira Standard + Confluence + Guard	$17,53	$21 036	$63 108
Jira Premium + Confluence + Guard	$24,16	$28 992	$86 976

Расчёт линейный. В нём нет скидок за объём, нет роста цен за три года и нет Marketplace-приложений, которые в облаке тарифицируются отдельно. Точную сумму покажет калькулятор на сайте Atlassian.

Что положить на другую чашу весов: стоимость продления Data Center до 2028 года, сервер и база данных, время администратора, а также разовые расходы на саму миграцию. По нашему опыту, именно миграцию чаще всего недооценивают: инвентаризация, тестовые прогоны и обучение занимают больше, чем ожидают.

Проверки 4–6: приложения, скрипты и права

4. Marketplace-приложения

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

Для каждого оставшегося приложения ответьте на четыре вопроса. Есть ли у него облачная версия. Совпадают ли функции, которые вы используете. Сколько оно стоит в облаке на ваше число пользователей. Где вендор приложения хранит и обрабатывает данные. Последний вопрос возвращает к проверке 1: облачное приложение может работать на инфраструктуре своего вендора, а не Atlassian.

5. ScriptRunner и самописные доработки

В Data Center многое держится на ScriptRunner и собственных плагинах: валидаторы переходов, вычисляемые поля, массовые операции, ночные отчёты. В облаке другая модель выполнения. Скрипты, которые обращаются к внутреннему API сервера или напрямую к базе, придётся переписать или заменить правилами Jira Automation. Самописные серверные плагины в облако не устанавливаются.

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

6. Схемы прав и группы

Схемы прав, роли проектов, уровни безопасности задач и группы из корпоративного каталога за годы обрастают исключениями. При переносе легко получить ситуацию, когда сотрудник видит в облаке больше, чем видел раньше. Для единого входа и централизованного управления доступом в облаке понадобится Atlassian Guard, который учтён в таблице стоимости.

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

Проверки 7–8: интеграции и лимиты

7. Интеграции

Data Center обычно стоит во внутренней сети, и интеграции с ним строились как внутренние. Репозитории и CI/CD, мониторинг, учётные системы, корпоративный портал, боты в мессенджерах. После переезда трекер окажется снаружи. Каждой интеграции понадобится либо доступ из интернета к внутренней системе, либо обратная схема с вебхуками и промежуточным сервисом. Оба варианта нужно согласовать со службой информационной безопасности.

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

8. Лимиты API и вложений

В облаке действуют ограничения на частоту запросов к API и на размер вложений. Значения зависят от тарифа и меняются, поэтому сверяйтесь с актуальной документацией Atlassian, а не с чужими статьями. На Data Center ваши интеграции могли без ограничений опрашивать сервер каждую минуту. В облаке такой отчёт или синхронизация может упереться в лимит.

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

Проверки 9–10: план отката и альтернатива

9. План отката

План отката пишут до миграции, а не во время инцидента. В нём должно быть:

1. Тестовая миграция на копии данных и её результаты.
2. Критерии приёмки: что проверяем, кто подписывает.
3. Период заморозки изменений в Data Center перед переключением.
4. Решение о том, что делать с задачами, созданными в облаке за время пилота.
5. Точка невозврата: дата, после которой Data Center переводится в режим только для чтения.
6. Ответственный, который принимает решение об откате.

Чем дольше команды работают в облаке, тем дороже откат: новые данные придётся переносить обратно. Поэтому сам откат проверяют на тестовом прогоне.

10. Альтернатива: self-hosted на сервере в Казахстане

Если проверка 1 или 3 провалена, честный вопрос звучит так: нужна ли именно Jira. Self-hosted таск-трекер на сервере у казахстанского хостера или в собственном дата-центре оставляет данные в Казахстане и оплачивается в тенге по договору.

Один из вариантов — Plane. Community Edition под лицензией AGPL-3.0 бесплатна без лимита пользователей. Платные self-hosted версии Commercial и Airgapped добавляют SSO, LDAP и детальные права доступа, а по функциям self-hosted не отстаёт от облака. Штатный импортер из Jira Server и Data Center переносит проекты, задачи, комментарии, вложения, статусы, связи, спринты и пользователей. Автоматизации, дашборды, JQL-фильтры, скрипты ScriptRunner и схемы прав не переносятся, но их, как видно из проверок 5 и 6, придётся пересобирать и при переезде в облако. Порядок работ мы описали в статье Миграция с Jira на Plane.

Сводная таблица: проверка → как проверить → что делать при провале

№	Проверка	Как проверить	Что делать при провале
1	Персональные данные	Карта проектов и вложений, решение о месте хранения	Обезличить данные или выбрать self-hosted в РК
2	Регион хранения	Сверить список регионов с требованиями компании и партнёров	Исключить облако из вариантов
3	Стоимость на три года	Расчёт по прайсу плюс приложения и миграция	Сократить состав подписок или сравнить с self-hosted
4	Marketplace-приложения	Реестр, облачные версии, цены, место хранения данных	Найти замену, отказаться или отложить переезд
5	ScriptRunner и плагины	Выгрузка скриптов, группировка по назначению	Переписать, заменить правилами, заложить время
6	Схемы прав	Тестовые учётные записи по ролям	Упростить схемы до миграции
7	Интеграции	Реестр с владельцами и направлением данных	Перестроить на вебхуки, согласовать с ИБ
8	Лимиты API и вложений	Нагрузочный прогон на тестовом сайте	Переделать опрос на события, разгрузить отчёты
9	План отката	Тестовая миграция и тестовый откат	Не переключаться, пока откат не проверен
10	Альтернатива self-hosted	Сравнение стоимости и требований с облаком	Пилот альтернативного трекера на одной команде

Если провалены проверки 1–2, дальше по списку можно не идти: облачный сценарий закрыт. Провалы в 3–8 означают дополнительную работу и бюджет. Без пункта 9 переключаться нельзя ни при каком раскладе.

Как мы это делаем

Мы начинаем с диагностики инсталляции: инвентаризация проектов, приложений, скриптов, прав и интеграций, разговор с бухгалтерией и службой информационной безопасности. По итогам клиент получает ответы на десять проверок и сравнение двух сценариев — облако Atlassian или self-hosted трекер в Казахстане. Затем переносим одну команду в пилотном режиме, проверяем права, интеграции и откат и только после этого масштабируем на остальные проекты.

Подробности о процессе и составе работ — на странице внедрения таск-трекеров Jira и Plane.

---

Источники. Таймлайн Data Center: atlassian.com/enterprise/data-center. Цены Jira, Confluence и Guard: прайс-лист Atlassian. Регионы хранения данных: Atlassian, data residency. Plane: plane.so/pricing и репозиторий на GitHub. Цены на октябрь 2026 года при годовой оплате и могут меняться.

Термины простыми словами

Data residency

Возможность выбрать, в какой стране облако хранит ваши данные. Регион определяет страну хранения, но Казахстана в списке Atlassian нет.

Atlassian Guard

Платное дополнение Atlassian для единого входа сотрудников и централизованного управления доступами в облаке. Оплачивается отдельно за каждого пользователя.

Marketplace-приложения

Дополнения к Jira от сторонних разработчиков. Не у всех есть облачная версия, а облачные могут хранить данные у своего разработчика, а не у Atlassian.

ScriptRunner

Популярное дополнение для Data Center, на котором пишут собственные проверки, вычисляемые поля и отчёты. В облаке такие скрипты обычно переписывают или заменяют правилами Jira Automation.

Вебхук

Автоматическое уведомление, которое одна система отправляет другой, когда что-то произошло, например изменилась задача. Позволяет облачной Jira сообщать внутренним системам о событиях без постоянных опросов.

Лимиты API

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

План отката

Заранее расписанный порядок возврата на старую систему, если переезд пошёл не так. Включает тестовую миграцию, критерии приёмки и точку невозврата.

Self-hosted

Трекер на сервере у казахстанского хостера или в своём дата-центре. Снимает вопрос хранения данных за рубежом, а хостинг оплачивается в тенге по договору.