クラウドへの移行の計画

description

セルフホスト型の Jira または Confluence からアトラシアンのクラウド製品に移行する場合のチェックリストです。サーバー製品からクラウド製品への移行の計画に必要なすべての情報をご確認ください。

このガイドでは、Jira または Confluence の Server または Data Center からクラウドへの移行に関する計画の概要について案内します。最初に、アトラシアンのクラウド製品への移行の詳細を確認し、移行でよくある質問に目を通すことをおすすめいたします。 

クラウドへの移行はいくつかのフェーズで構成されます。すべての項目を完了していることを確認するために、次のチェックリストをご利用ください。

評価からローンチまでの、クラウド移行の 6 つのフェーズを示すタイムライン。

自分の権限を確認する

このガイドの一部のステップでは上位の権限が必要になります。開始する前に、次の点をご確認ください。

  1. サーバー製品でシステム管理者グローバル権限を保持していること

  2. クラウド サイトで site-admins グループに所属していること

フェーズ 1: 評価

移行の 3 - 6 ヶ月前

移行の最初のステップは、現在の状態と目標を理解することです。このフェーズでは、クラウドへの移行が適切な判断かどうかを評価し、予想される変更を確認します。

アトラシアンのサポート提供内容の確認

サーバーからクラウド製品への移行のプロセスでは、アトラシアンの移行のエキスパートをいつでも利用できることが非常に重要です。弊社ではお客様の移行をお客様環境の最大レベルのアップグレードと見なし、各ステップの支援を行っています。

アトラシアンでのクラウド移行のサポートについてご確認ください。

クラウド製品とサーバー製品の比較

最初に、Jira および Confluence のサーバー製品とクラウド製品の違いを確認します。また、サーバー製品とクラウド製品でのユーザー管理の違いについてもご確認ください。

クラウドおよびサーバー製品の現在のランドスケープの監査

クラウドおよびサーバー環境にどの製品が存在するか、およびそれらを使用しているのは誰であるかを理解することは、最初の重要なステップです。意図しないセルフホスト型インスタンスやクラウド サイトが存在する場合があります。ランドスケープの完全な把握は移行戦略の計画に役立ちます。

アプリの監査

移行を決定する前に、アプリやカスタム連携を確認し、クラウド製品に必要なものと利用可能な移行パスを判断します。この手順に役立つアプリの監査クラウドへの移行方法に関するアドバイスとベスト プラクティスをご用意しています。

セキュリティおよびコンプライアンス要件の確認

アトラシアンのセキュリティ、プライバシー、およびコンプライアンス ポリシーの詳細については、Trust at Atlassian をご確認ください。この時点で、クラウド製品が要件を満たしていることを確認するために、調達チームやセキュリティ チームとの連携が必要となる場合があります。

関連リソース:

クラウド製品の価格の評価とプランの比較

クラウド サブスクリプションの費用を除き、クラウドへの移行に対する費用は発生しません。ただし、支払いオプションおよび全体的なコストの評価は引き続き必要です。大規模な環境では、移行の支援にパートナーが必要かどうかや、クラウドへの移行後に必要なサポート レベルなどを検討する必要もあります。

関連リソース:

tip/resting Created with Sketch.

既存のサーバーおよび Data Center のお客様向けに、ご自身に最適なペースでクラウド製品を検討して移行できる、無料の延長クラウド トライアルを提供しています。

パートナーが必要かどうかを評価する

アトラシアンのソリューション パートナーは、お客様の チームの専門知識のレベル、移行の複雑さ 、タイムラインに応じて最小限の労力でクラウド製品に正常に移行できるように訓練されています。 

移行要件が複雑な場合や、アトラシアンのサポート チームが提供するガイダンスの実行に支援が必要な場合は、パートナーと作業に取り組むことをおすすめいたします。

次のような移行の場合にパートナーの利用をおすすめします。

  • このプロジェクトを支援する内部リソースが制限されている場合

  • ユーザー受け入れテスト、サーバーのアップグレード、ユーザーのトレーニングなどの、アトラシアン サポートのスコープを超えた取り組みへの支援が必要な場合

  • 移行プロジェクトの管理、計画、および実行に支援が必要な場合

  • 複雑な統合シナリオがある場合

  • 5 つ以上のビジネス クリティカルなアプリを移行する必要がある場合

  • 特定のセキュリティおよびコンプライアンス要件がある場合

  • 1,000 人以上のユーザーの移行が必要な場合

移行を支援するパートナーをお探しの場合はご連絡ください

クラウド製品の今後の見通しについて

クラウド製品のプラットフォーム、製品、移行ツールおよびサポートについてはアトラシアンのロードマップをご参照ください。移行の計画および実施には時間がかかるため、クラウド製品の現在の機能ではなく今後の状況を見据えて計画を行うことをおすすめします。

フェーズ 2: 計画

移行の 2 - 3 ヶ月前

移行を決定したら、プロジェクトの完了に必要な手順と戦略を確認します。

FAQ の確認

サーバー製品からクラウド製品への切り替えのよくある質問を確認します。すべての考慮事項を確認するのに役立ちます。

無料の延長クラウド トライアルへのサインアップ

セルフホスト型製品の既存のお客様はクラウド延長トライアルを活用して、ご自身に最適なペースで、確認、テスト、およびクラウド製品への移行を行えます。追加コストは不要です。

tip/resting Created with Sketch.

クラウド製品への切り替えを検討されているすべての方に、これらのトライアルや、弊社の他のクラウド移行の無料トライアルを活用していただくことをおすすめします。このトライアルは弊社の標準のクラウド トライアルよりも長期間ご利用いただけるため、ユーザーは移行の計画に必要な時間と柔軟性を確保できます。

組織のセットアップ

組織を使用すると、社内のすべてのアトラシアン クラウド ユーザーを 1 か所で確認し、ユーザーのアカウントを管理し、SAML SSO などのセキュリティ機能をセットアップすることができます。組織は、社内で 2 つ以上のサイトを使用していて、すべてのサイトと製品、およびそれらにアクセスできるユーザーを 1 か所で確認したい場合に非常に便利です。組織はすべてのサイトで自動的に作成されますが、既存の組織にサイトを転送することもできます。詳細については「Atlassian 組織のセットアップ」をご参照ください。

ドメインの認証とユーザー アカウントの要求

ドメインの認証によって、企業のドメインの所有権を認証したり、そのドメインのユーザー アカウントを要求したりできます。これによって、企業のドメインを持つ Atlassian アカウントをより詳細に管理したり、管理対象アカウントにセキュリティ ポリシーを適用したりすることができます。選択した方法に応じて、ドメインの検証には最大で 72 時間がかかる場合があるため、これは早期に行う必要があります。 

Atlassian Access が必要かどうかの評価

Atlassian Access は、組織のすべてのアトラシアン クラウド製品全体での強化されたセキュリティおよび一元管理のための、企業規模のサブスクリプションです。SAML SSO やユーザー プロビジョニングを使用する予定がある場合、またはクラウド製品で外部ディレクトリからグループを同期する予定がある場合、Atlassian Access をサブスクライブする必要がある場合があります。 

Atlassian Access のサブスクリプションを最大限に活用するには、弊社のサポート対象のアイデンティティ プロバイダーも必要です。アイデンティティ プロバイダーをお持ちではない場合、Atlassian Access 内で無料の Okta アカウントにサインアップできます。Okta アカウントでは、アトラシアン クラウド製品に対する費用は発生しません。詳細情報

関連リソース:

データのサイズと複雑さの評価

セルフホスト型インスタンスを確認し、データの量、ユーザー数、データのサイズまたは複雑さを軽減できるかどうか (例: Jira でのカスタム ワークフローの標準化) を確認します。引き継ぐデータの量によっては、無制限のストレージが提供される、クラウド製品の Premium プランが必要な場合があります。

移行方法の選択

移行に使用する方法は、全体的な戦略によって異なります。移行するデータの種類 (プロジェクトかスペースか) およびチーム、クラウド製品とサーバー製品のどちらで統合する必要があるかどうかなどについて検討する必要があります。

実現したい内容とそこに至るまでの潜在的なパスを明確に理解すると、移行に最適な方法を選択しやすくなります

チームを集める

サーバー製品からクラウド製品への移行は、ユーザーのエクスペリエンスやワークフロー、組織全体のさまざまなステークホルダーに影響する可能性があります。移行に関心を持っていたり、移行の影響を受けたりする個人やステークホルダーに、できるだけ早い時期に連絡することをおすすめします。

移行計画の作成

プロジェクト計画を準備します。これには、計画済みのアクティビティ、おおよそのタイミング、各タスクの所有者と依存関係が含まれます。

フェーズ 3: 準備

移行の 1 - 2 ヶ月前

メンバー、データ、環境のそれぞれについて、移行の準備を整えます。

計画の連絡

チーム メンバー、ステークホルダー、ユーザーへの移行計画の共有を開始します。最新の情報を伝えるためのタイミングと配信方法を検討します。

アプリの移行パスの決定

アプリの監査後、クラウド製品で使用するアプリの移行方法を検討する必要があります。これも移行のタイムラインに含めるようにします。

サポート対象のサーバー バージョンを使用していることの確認

移行方法に基づき、サポート対象のサーバーまたは Data Center バージョンを使用していること、移行前にアップグレードが不要であることを確認します。 

関連リソース:

セルフホスト型インスタンスのクリーンアップ

セルフホスト型インスタンスを確認し、移行前にクリーンアップできる情報を特定します。特に、グループや権限を確認したり、カスタマイズを最小化する方法を確認したり、非アクティブなプロジェクト (Jira の場合) やスペース (Confluence の場合) を特定したりすることをおすすめします。弊社のテスト ガイドでは、より詳細なデータ クリーンアップの推奨事項についてご案内しています。

匿名アクセス設定の確認

JiraConfluence のいずれも、匿名またはパブリック アクセスを許可するように構成できます。つまり、ログインしているかどうかにかかわらず、すべてのユーザーがサイトにアクセスすることを許可できます。クラウド製品に移行する前に、匿名アクセスの設定がクラウド製品で必要なアクセス設定に一致していることを確認する必要があります。詳細はこちらをご覧ください

シングル サインオンのセットアップ 

クラウド サイトでシングル サインオン (SSO) を使用する予定の場合、移行時にユーザーがスムーズに利用開始できるよう、SSO を事前にセットアップすることをおすすめします。SSO をセットアップする前に、組織のドメインを認証する必要があります。SSO を使用するには Atlassian Access のサブスクリプションが必要である点にご注意ください。Atlassian Access は 30 日間無料で試用できます。

(Jira のみ) クラウド サイトのユーザー階層が適切であることの確認

Jira Cloud の年間サブスクリプションをお持ちの場合、インポートを計画している全ユーザーに対して十分なユーザー層であることを確認します。たとえば、125 ユーザーのインポートを計画している場合、インポートを成功させるためには 101 ~ 200 ユーザーの年間ユーザー階層を持っている必要があります。これは、年間プランの場合にのみ適用されます。インポートの失敗を防ぐため、移行の間は月間サブスクリプションを保持し、移行の完了後に年間サブスクリプションに切り替えることをおすすめします。

(Jira のみ) ユーザーの移行戦略の選択

Jira ユーザーの最適な移行戦略の選択については、弊社のガイダンスをご確認ください。 

フェーズ 4: テスト

移行の 2 - 4 週間前

移行が正常に完了するかどうかや所要時間を判断し、本番環境での移行チェックリストを作成します。

データのバックアップ

使用する移行方法にかかわらず、移行前に Jira または Confluence のセルフホスト型インスタンスをバックアップすることをおすすめします。クラウド サイト内にデータが存在する場合、同様に安全のためにバックアップします。

テスト移行の実行

移行をテストして、プロセスに慣れ、すべてが期待通りに動作することを確認し、本番環境での移行の明確なタイムラインを確立します。

tip/resting Created with Sketch.

このステップは小規模な移行であっても実行することを強くおすすめします。これは、本番環境での移行の成功を保証し、ダウンタイムを予想し、潜在的な問題を事前に検出するのに最適な方法です。

アプリのインストールまたは移行

テストの一環として、クラウド製品で使用する予定の任意のアプリをインストールまたは移行することをおすすめします。これらが適切に機能することをテストして、想定通りに動作することを確認します。

ユーザー受け入れテストの実施

一部のエンドユーザーにテスト サイトを使用して一般的な日常タスクを模倣してもらう、ユーザー受け入れテスト (UAT) を実施することをおすすめします。これによって、予期していない問題を把握できるだけでなく、組織が変更に対して準備することができます。手順の詳細については移行テスト ガイドをご参照ください。

手順書とタイムラインの構築

移行手順書は、移行を完了するために必要な作業をまとめた詳細なチェックリストです。これを作成することで、本番環境への移行を計画どおりにスムーズに実施できます。手順書には、プロセスの各ステップ、それらのステップで必要な手順、それらを実施する担当者、予想される時間などを含める必要があります。

本番環境への移行時間の選択

トラブルシューティングにかかる時間を考慮したうえで、移行にかかる時間を判断します。夜間、週末、あるいはセルフホスト型またはクラウド製品へのチームのアクセス頻度が低い時間に移行を実施することを検討します。これにより、サーバー製品とクラウド製品との間でデータの矛盾が発生するリスクを減らすことができます。

本番環境の移行期間中のサポートについて

本番環境の移行期間中に、発生した問題を迅速に解決するためにアトラシアン サポートへのアクセスが必要になる場合があります。 

週末や祝日に移行を行う場合、または 1,000 人以上のユーザーをクラウド製品に移行する場合、2 週間以上前にお知らせください。弊社で人員を用意し、移行を支援いたします。

トレーニング資料の準備

ユーザーにとって重要なすべての変更を把握して準備するようにします。これは、ログイン方法、新しい URL、アプリへの変更、UI の違いなどです。UAT テストによって、ユーザーが抱く疑問や有用なトレーニングなどを推測することができます。

計画の連絡

発生する問題やエラーについて、ユーザーにどのように警告するかを決定します。この段階では、移行のコミュニケーション計画に以下のような内容を含める必要があります。

  • 移行のタイミング
  • ユーザーが想定すべきダウンタイム
  • 移行中はあらゆる変更を加えないよう、ユーザーに依頼する
  • 移行後の古いサイトへの影響。アクセスまたは読み取りが引き続き可能かどうか
  • 新しい URL
  • サインイン方法
tip/resting Created with Sketch. また、今後の移行についてユーザーに周知しやすくするため、Jira または Confluence でサイト全体のバナーを使用することもおすすめします。

フェーズ 5: 移行

移行当日

データとユーザーがクラウド製品に移行され、すべての問題は解決済みです。

本番環境への移行の実行

あと少しです。移行手順書とタイムラインで指定されている手順を利用し、データをクラウド製品にコピーします。

アプリのインストールまたは移行

クラウドで使用する予定のアプリをインストールまたは移行します。

移行されたデータの QA

データが想定どおりに移行され、すべてが適切に動作していることを確認します。ここで推奨される確認内容については、弊社のテスト ガイドをご参照ください。

サーバー製品を読み取り専用に設定する

サーバー インスタンスを引き続き実行する予定がない場合、移行後に Confluence Server を読み取り専用モードに設定して切り替えを支援することができます。

Jira Server に明示的な "読み取り専用" モードはありませんが、"参照" のみを許可する権限スキームを作成してそれをすべてのプロジェクトに適用することができます。

ユーザーを新しいクラウド サイトにリダイレクトする

サーバー製品にアクセスするユーザーを新しいクラウド サイトの URL にリダイレクトするため、Jira または Confluence に、アクセス先を通知するサイト全体のバナーを適用できます。

フェーズ 6: ローンチ

移行の 1 - 4 週間後

ユーザーのクラウド製品の利用開始を支援し、クラウド管理者としてのスキルを磨き、サーバー製品の使用を終了します。

チームを迎える

移行が完了したこと、移行の背景、ユーザーで必要な操作をすべてのユーザーに通知します。これには、ブックマークすべき新しいリンク、ログイン方法、再設定する必要があるデータ (パスワードやアバターなど)、アプリや機能への変更、提供されるトレーニング、支援が必要な場合の問い合わせ先などが含まれます。

tip/resting Created with Sketch.

Atlassian Cloud モバイル アプリについてもお知らせください。

安定期間

ローンチ時の問題やフィードバックを特定および優先付けるための専用の時間を確保し、優先度の高い項目を解決します。

(Jira のみ) 次世代プロジェクトを試す

セルフホスト型の Jira とは異なり、クラウドの Jira SoftwareJira Service Desk では次世代プロジェクトが提供されます。次世代プロジェクトは最新のプロジェクト タイプで、作業を素早く開始したい自律的なチームを支援するために設計されています。Jira 管理者に支援を依頼したり、複雑な機能を使用したりすることなく、プロジェクトを素早く開始して、独自のワークフローを設計できます。新しいクラウド管理者として、これらのプロジェクトの詳細と、クラウド製品を利用するようになったチームへのメリットについて確認する時間を確保することをおすすめします。

(Confluence のみ) 新しいエディタを最大限に活用する方法を確認する

Confluence Cloud では編集エクスペリエンスの改善をロールアウトしており、サーバー製品では利用できない便利な機能やコンテンツの装飾方法を提供しています。導入済みの機能や今後の予定については「Confluence Cloud エディタのロードマップ」を参照してください。

サポートおよび保守体制への移行

解決すべき大きな問題はなくなりましたか? チームの標準サポートおよび保守プロセスを SaaS アプリケーション用に移行しましょう。

クラウド製品のセキュリティのベスト プラクティスの実装

会社のもっとも重要な作業を安全に行うため、ベスト プラクティスを活用して強固な基盤を作成しましょう。

クラウド製品の最新情報のフォロー

クラウド管理者として、クラウド プラットフォームおよび製品の最新情報を入手することをおすすめします。クラウド製品では、最新の機能とバグ修正を即座に利用できます。インストール、アップグレード、およびパッチはアトラシアンによってシームレスに管理されるため、週末のアップグレード対応は不要です。 

おめでとうございます

移行はこれで終了です。お疲れさまでした。

詳細情報とサポート

移行をサポートする多数のチャネルをご用意しています。


最終更新日: 2020 年 2 月 6 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.