Atlassian Cloudへの移行 ── Data Center版から乗り換えて得た知見

はじめに

こんにちは。コーポレートエンジニアリング部ITサービスブロックの高橋です。

当社はJira / Confluence Data Center版からAtlassian Cloudに移行しました。今回は、実務で直面した課題を交えてその経験をお伝えします。

目次

なぜ移行したのか

私たちが移行を検討した理由は大きく2つあります。1つはユーザ目線、もう1つは管理者目線です。

ユーザ目線として、Data Center版では最新機能が利用できず、ユーザ体験を損なっていました。

• UIの違い：Confluenceのライブ編集エディタなど、Cloud版のUI改善がData Center版には反映されない
• SaaS間連携の制約：Slackとの連携などCloud前提の機能が多く、Data Center版では手段が限られる
• 自動化機能の差：Jira AutomationのトリガーやテンプレートがCloud版の方が充実している
• Cloud限定の新機能：Atlassian IntelligenceやJiraのチーム管理対象プロジェクトが利用できない

管理者目線では、管理・運用負荷やセキュリティ対応の負担が増していました。Cloud版ではこれらが以下のように改善されます。

• 定期メンテナンスによる停止 → 自動アップグレードによりダウンタイムが不要に
• 都度必要になるストレージ増設 → Atlassianが管理するため不要に
• 定期アップグレードや脆弱性対応 → 自動適用されるため運用負荷が軽減
• ユーザ管理や権限管理の運用負荷の増大 → SCIMによる自動プロビジョニングが利用可能に
• セキュリティ対策の個別対応 → Atlassian Guardによるデータ保護や脅威検知の一元管理が可能に
• Data Center版のサポート終了（2029年3月28日にEOL予定）

以上を踏まえ、最終的にEOLの明確化が決定打となり、ユーザ利便性の向上と管理コストの削減を目的にAtlassian Cloudへの移行を決めました。

移行の進め方

移行は「調査→検証（UAT）→本番」の段階で進め、2024年に情報収集と方針決定、2025年上期に移行準備とUAT、下期に本番移行するスケジュールで実施しました。

移行作業の大部分はSIに委託しました。具体的には以下のような作業です。

• Atlassian純正移行ツールによるデータ変換・投入

  • Jira / ConfluenceのデータをCloud Migration Assistantで変換・投入し、ボードやページの移行可否を検証するためにツールの最新版で再移行テストを実施。

• 添付ファイル移行（Jira / Confluence）の個別実行と複数回の実施

  • 添付ファイルは別工程で移行し、Jira添付→Confluence添付の順で実行。完了しない箇所は再移行・調整を繰り返した。

• 本番移行の手順実行（停止→再移行→確認）

  • 旧環境の停止（夜間）→Jiraデータ移行→Confluenceデータ移行→データ確認、という順序で本番移行を実施（移行日程・停止時間の調整を含む）。

• アプリ/マクロの個別移行・チューニング

  • ユーザーマクロやアプリ固有の変換不具合に対し、対象スペースでの変換・調整・チューニングを実施。必要箇所は再移行や個別チューニングを依頼。

• リダイレクト/旧環境の読み取り専用化等の運用設定

  • 移行後のリダイレクト設定や旧環境を読み取り専用に切り替える作業を実施。

また、移行後のリスクに備え、旧Data Center版の環境は保険的に半年間維持する方針としました。

アプリ移行を重視した理由

（※以下、旧来の呼称である「アドオン」を含め、本記事では「アプリ」と表記します）

当社の環境は、長年の運用で蓄積されたデータ量が膨大であり、細部まで逐一確認できる状況ではありませんでした。そのため、一般的な表示や日常機能の微細な差分をすべて確認するのではなく、データ変換で致命的な問題が発生しないことを前提としました。移行時の最重点は、データ変換だけでは対応できないアプリの検証に置きました。

アプリ移行が厄介なのは、「変換してみないと変換精度や変換後の実行エラーが判明しない」点です。

Data Center版のマクロやカスタムスクリプトは、Atlassian Cloudの標準機能に置き換えられる場合もあれば、別のアプリで代替するしかない場合もあります。代替先に移す場合でも挙動や仕様が異なるため、変換ツールがあっても正常に動作するか、どの程度エラーが発生するかは試してみないと分かりません。

そのため実務では、検証環境で変換テストを行い、UATで例外を拾い、検出した問題をSIに返して対応・再変換するという反復作業を行いました。

すべてを完璧に移行するのは現実的でないため、アプリの使用件数など影響度で優先順位を付けました。軽微・特殊な例外はユーザ側で手作業により補完する方針です。

事前準備

組織統合の整理

移行検証で意外に問題となったのが、グループ内の別組織がすでにAtlassian Cloudを契約していた点です。

このまま別々の組織として運用すると、SSOやプロビジョニングの設定も分断され、ユーザ管理や権限管理の運用コストが大きくなるため、組織を統合する方針としました。

具体的には、既存の組織を当社側で管理する形に移管し、その組織内でサイトを分けて新規サイトに移行する構成としました。既存環境を壊すことなく統合でき、複数サイトのアクセス権を組織グループで一元管理できるようになりました。

このような対応は、組織間の調整やAtlassianとの事務的な手続きを伴います。技術的な作業とは別に時間がかかるため、移行の早い段階で整理しておくことで、後工程での手戻りを防ぐことができます。

SSO/SCIMと権限設計

Atlassian Cloudでは、Data Center版と比べて認証・ユーザ管理の考え方が変わります。Data Center版でもSSO自体は利用できますが、Atlassian Cloudでは組織単位でのユーザ管理やサイト単位でのアクセス制御、SCIMによる自動プロビジョニングが前提です。ユーザやグループの管理がよりIdP寄り（当社ではEntra ID）になります。

この違いにより、単純に既存の権限設計をそのまま移すのではなく、ユーザ管理と権限管理をあわせて見直す必要があると判断しました。

• Entra IDを中心にSSOを構成し、ログインを一本化（以前と同様）
• Entra IDの組織グループを活用した権限管理に移行（Data Center版では静的グループを中心に、一部スクリプトで擬似的な同期を行っていた）
• SCIMによる自動プロビジョニングを導入し、手動・スクリプトベースのユーザ/グループ管理を削減
• 移行時はユーザ重複やドメインを事前に整理し、UATで実際のアクセスを確認

Data Center版では実現できていなかった「IdP側のグループと権限の連動」を前提に設計し直したことで、移行後のユーザ管理の手間を大きく減らすことができました。

グループ同期の注意ポイント

SCIMによるグループ同期を行う際、同期したいグループと同名のグループが既に存在する場合、同期前に変更内容のレビューがUI上で求められる点にも注意が必要です。この場合、どのユーザが追加/削除されるかを事前に確認し、承認したうえで同期を実行する必要があります。

既存グループとの衝突が発生すると、そのままでは同期できないケースもあるため、グループ設計や命名の整理を事前に行っておくことが重要です。

support.atlassian.com

UAT（ユーザ受け入れテスト）の設計と運用

UATは約1か月間設けました。検証用のAtlassian Cloud環境を構築し、そこにData Center版のデータを変換して投入し、ユーザが自由に触れる状態で検証を進めました。検証環境のデータは本番に引き継がれません。したがって検証で「再設定が必要だ」と判明した箇所は、検証中に手順を確認してもらいました。本番の利用開始後に改めて同じ手順で再設定していただく前提です。検証環境は「変換後の動作確認と再設定手順の確認の場」と位置づけました。再変換で潰しきれないものを本番で再設定していただく運用にしました。

ユーザへの案内内容

• 基本動作：ログインや基本機能に問題がないか。
• 業務の継続性：普段の業務がこれまで通りスムーズに行えるか。
• アプリの重点確認：マクロや自動化を多用しているユーザには、アプリの動作を入念に確認するよう依頼。
• ライトユーザへの負荷設計：複雑な機能を使っていないライトユーザには、単純に「いつもの業務ができるか」だけを確認してもらい、全体の負担を抑える。

アプリ確認を支えるガイド

ユーザが確認しやすいように、ガイドとなる資料を配布しました。資料は対象アプリごとに「どこで使用されているか」「移行されないもの」「正常に移行される想定のもの」「各自で再設定や運用変更が必要になりそうなもの」をざっくりリストアップしたものにしました。

問い合わせの集約方法

問い合わせや不具合報告は専用のSlackチャンネルに集約し、Slackワークフローでフォーム化して問い合わせを集計できるようにしました。報告された事項は順次SIに確認・修正を依頼しました。

本番移行

本番移行のタイムスケジュールは以下のとおりです。

• 10/03（金）：検証環境の再構築
• 10/06（月）〜 10/10（金）：添付ファイル移行（複数回実施）
• 10/31（金）22:00：Data Center版の本番環境を停止・読み取り専用に設定
• 11/01（土）深夜〜11/02（日）：本番の移行作業（Jiraの移行対応→Confluenceの移行対応）
• 11/02（日）：移行後データ確認、リンク修正、設定修正
• 11/03（月）：当社側でのデータ確認・結果判定
• 11/04（火）：Atlassian Cloud運用開始
• 予備日：移行の結果判定がNGの場合や追加対応が必要な場合に備え、11/22（土）〜11/24（月）を予備日として確保（連休をターゲットに）

事前にUATで十分に検証していたため、本番移行で大きな問題は発生しませんでした。また、UAT期間中にアプリ周りのデータ変換を複数回繰り返していたことにより、変換精度はある程度向上しており、本番時のリスクを抑えることができました。

移行後の対応

権限の付け替えとAPI活用

本番移行の完了後、各スペースの権限を既存の静的グループからEntra IDと同期した組織グループに付け替えるにあたり、Atlassian CloudのAPIを利用して一括付け替えを実施しました。

あらゆるグループを差し替えたわけではなく、トップレベルや本部単位の主要グループを対象に差し替えています。これは入退社によるアクセス権管理を自動化するためです。

権限の付け替えは対象が増えると手作業では現実的ではないため、スペース単位で整理した内容をもとにAPIを使って一括で処理する形にしました。

基本的には以下の流れで進めました。

1. スペース一覧を取得
2. 既存の権限（グループ）を取得
3. 新しいグループ構成との差分を整理
4. APIで権限を追加/削除する

また、権限の付け替えは一度にすべて入れ替えるのではなく、まず新しいグループの付与が正しく行われていることを確認したうえで、既存の権限を削除するようにしました。

実際にハマったポイント

Atlassian CloudのAPIは、トークンの種類によってリクエスト方法が変わります。

• スコープなし（従来のAPIトークン）
• スコープ付きトークン（推奨）

それぞれリクエストURLの形式が異なります。

• Confluence（スコープなし）：https://<site>.atlassian.net/wiki/rest/api/space
• Confluence（スコープ付き）：https://api.atlassian.com/ex/confluence/<cloudId>/wiki/rest/api/space
• Jira（スコープなし）：https://<site>.atlassian.net/rest/api/3/project
• Jira（スコープ付き）：https://api.atlassian.com/ex/jira/<cloudId>/rest/api/3/project

スコープ付きトークンではapi.atlassian.comベースのURLにCloud IDを含める必要があります。Cloud IDはサイトURLと異なる識別子であり、これを含めてリクエストを構築しないとAPIは動作しません。

Cloud IDは以下の方法で確認できます。

• admin.atlassian.comのURL/s/{cloudId}から確認
• https://<site>.atlassian.net/_edge/tenant_infoにアクセスして取得

詳細は公式ドキュメントを参照してください。

support.atlassian.com

support.atlassian.com

また、Atlassian CloudのAPIはバージョン（v2 / v3）によって仕様が異なります。基本的な操作は共通しているものの、レスポンス形式や扱える項目に差があるため、実装時にはドキュメントを確認しながら利用する必要があります。

外部サービスに残る旧URLへの対応

旧Data Center版の環境は保険的に半年間維持する方針としましたが、廃止後は完全にアクセスできなくなります。Jira / Confluence内のリンクは移行時にある程度変換されます。一方、SlackなどAtlassian外のサービスに記載されたURLは自動で置き換わらないため、そのままではリンク切れが発生します。

そのため、旧環境と新環境のページURLの対照表の作成をSIに依頼し、必要に応じて参照できるようにしました。これにより、移行後も外部に残っているリンクから該当ページを特定できるようにしています。（ページの一覧はData Center版ではDBから取得、Atlassian Cloud環境ではREST APIで取得可能）

移行を終えて

社内からの問い合わせ件数は全体で約100件でした。多くはアプリのデータ変換や表示差分、操作方法の違いに関するもので、致命的な障害は発生していません。

ただし、移行ツールやSI側の対応だけでは解決できない細かなケースもあり、一部ユーザ側で手動修正が必要になりました。主な例は次のとおりです。

• マクロの差し替え：旧環境で使用されていたマクロの一部がAtlassian Cloudで正常に表示されず、代替マクロへの差し替えや再作成が必要になった
• Plans/ガントの再設定：表示やフィルタ設定の一部が引き継がれず、再設定が必要になった
• JQLの書き換え：旧環境で使えていたJQL関数がAtlassian Cloudで使えず、代替クエリへの書き換えが必要になった
• Automationの再構築：トリガーや参照フィールドの仕様差で動作しないルールがあり、修正・再作成が必要になった

この大規模な移行プロジェクトは何が起きるか分からず、計画初期から漠然とした不安がありました。移行ツールの質も上がっているからか、特に大きなトラブルもなく移行でき、ほっとしました。

アプリ周りの移行が最も大変でしたが、見込み通りだったのは幸いでした。変換方法についてSI側と協議しながら再変換を繰り返すなど、手探りな部分はどうしても発生します。手動での修正は、対象が多すぎると現実的でないため、できる限り変換で潰していくことが重要です。変換処理は繰り返す前提で、早いうちから検証を進めることをおすすめします。

おわりに

Data Center版からAtlassian Cloudへの移行は技術的なデータ移行作業だけではありません。機能面・運用面・契約・組織間調整と、多面的に検討する必要があります。UATを中心に据えて現場で検証し、APIを活用することで作業負荷を抑えられます。同様の移行を検討している現場の参考になれば幸いです。

ZOZOでは、テクノロジーを活用して社内の課題を解決する仲間を募集中です。SaaSの運用管理からシステム間連携・自動化まで、グループ全体の業務環境をよりよくするための取り組みにチャレンジしていきます。カジュアル面談も実施していますので、社内ITについて語りましょう！

ご興味のある方は、下記のリンクからぜひご応募ください。

hrmos.co