ArcGIS Enterprise ユーザーとしては、ビジネスの変化や組織のニーズの変化に伴い、移行が必要になる場合があります。ArcGIS Enterprise の世界において、「マイグレーション＝移行」にはさまざまな意味があります。新しいインフラストラクチャへの移行、オンプレミスからクラウドへの移行、あるいはある展開オプションから別の展開オプションへの移行が必要になるかもしれません。環境全体の移行に加え、プロモーションワークフローにおいて、開発環境やステージング環境などの本番前環境から本番環境へ、個々のコンテンツを移行する必要がある場合もあります。さらには、ArcGIS Online から ArcGIS Enterprise へ、あるいはその逆といった、製品間の移行を検討される場合もあるでしょう。
ご想像の通り、移行は定義するだけでなく、綿密に検討する必要がある複雑なプロセスとなり得ます。この ArcGIS Enterprise ブログでは、一般的な移行ワークフロー、利用可能なツールや移行手法、および移行シナリオに応じた各ツールのメリットや考慮事項について解説します。また、移行の準備を進め、ニーズに合った適切なアプローチを選択する際に検討すべき重要なポイントについてもご案内します。最後に、これまで取り上げた内容をまとめて理解を深めるため、移行シナリオの例をいくつかご紹介します。それでは、さっそく始めましょう！
※注記：本ブログ上に Kubernetes の記載がありますが、2026 年 11 月現在 ArcGIS Enterprise on Kubernetes は国内において未サポートとなります。また、本ブログは米国 esri が公開しているブログ記事をもとに作成しております。
（ https://www.esrij.com/services/maintenance/products/ ）
Jump to: Common migration workflows | Choosing your migration approach | Common questions to ask to determine the right migration path | Examples of common migration scenarios and recommended approaches
目次
一般的なマイグレーション（移行）ワークフロー
さて、ArcGIS Enterprise への移行が必要であることはわかっているものの、実際にはどのような意味を持つのでしょうか？まず、移行を検討する際に考慮すべき重要なポイントとして、環境全体の移行となるのか、それとも特定のコンテンツやワークフローの移行となるのかという点があります。こうした ArcGIS Enterprise 独自の移行に加え、組織のニーズの変化に応じて、ArcGIS 製品間の移行が必要になる場合もあります。これら2つのカテゴリーにおける一般的な移行シナリオをいくつか見ていき、どのワークフローを経ることになるのかを確認しましょう。
環境全体の移行
1. ArcGIS Enterprise を新しいインフラストラクチャへ移行する： 組織によっては、既存の ArcGIS Enterprise 展開を新しいインフラストラクチャへ移行する必要が生じる場合があります。その理由は多岐にわたりますが、例えば次のようなケースが挙げられます：
- より新しいバージョンのオペレーティングシステムを搭載したマシンへの移行を希望する場合。
- オンプレミスからクラウドインフラストラクチャへ、またはその逆への移行を行う場合。
- ミラー環境を構築することで、アップグレード中のダウンタイムを最小限に抑えようとする場合。
- 異なるマシンの使用を必要とする内部の変更。
- 理由が何であれ、この場合、ArcGIS Enterprise の展開全体（すべてのコンテンツとユーザーを含む）を新しいインフラストラクチャへ移行することになります。
2. ArcGIS Enterprise の展開オプション間の移行： ArcGIS Enterprise には、Windows、Linux、Kubernetes の 3 つの展開オプションがあります。当初は特定の展開オプションを使用して ArcGIS Enterprise をインストールしたものの、ビジネスニーズの変化に伴い、別の展開オプションに移行する必要が生じる場合があります。IT チームが他のクラウドネイティブソフトウェアの導入に注力しており、従来は Windows または Linux 上で稼働していた ArcGIS Enterprise を Kubernetes 上で利用したいと考えるケースもあります。また、Linux 上のソフトウェアをサポートする専門知識がより豊富であるため、当初 Windows にインストールされていた環境を移行したい場合もあるでしょう。繰り返しになりますが、この場合も、ArcGIS Enterprise の展開環境全体を移行することになります。
特定のコンテンツ、ユーザー、またはワークフローの移行
1. コンテンツの展開ワークフロー： 組織によっては、テスト、開発、品質保証の目的で、本番前の環境を指定している場合があります。その結果、本番前の環境と本番環境の間でコンテンツを移行する必要が生じる可能性があります。コンテンツの展開シナリオでは、通常、一度に個々のアイテムまたはアイテムのグループのみを移行します。
2. プロジェクトや共同作業のためのコンテンツの共有： 組織では、業務を支援するために複数の ArcGIS Enterprise 環境を運用している場合があります。プロジェクトやさまざまな業務のために、これらの環境間でコンテンツを共有する必要があるかもしれません。また、異なる ArcGIS Enterprise 環境を使用している複数のチームやグループが、共同作業のためにコンテンツを共有する必要がある場合もあります。このようなシナリオでは、業務を遂行するために、個々のアイテムまたはアイテムのグループを移行する必要があります。
ArcGIS 製品間の移行
ArcGIS Online から ArcGIS Enterprise へ、あるいは ArcGIS Enterprise から ArcGIS Online への移行： ArcGIS Online は、ArcGIS Enterprise と同じ基本的なマッピング、可視化、空間分析、およびコラボレーションツールを提供します。主な違いは、ArcGIS Online が SaaS（Software-as-a-Service）製品であるのに対し、ArcGIS Enterprise は自社ホスト型のソフトウェアであるという点です。場合によっては、セキュリティ、オンプレミスのデータへの接続、拡張性の選択肢などに関するビジネス上の要件が変化し、ArcGIS Online から ArcGIS Enterprise への移行が必要になることがあります。これは新しい製品への移行であるため、ビジネス上の要件に応じて、移行するユーザー、コンテンツ、およびワークフローを選択することになります。ArcGIS Enterprise と ArcGIS Online は別々の製品であるため、以前の環境と新しい環境の間にはいくつかの微妙な違いが生じます。
「移行」という言葉と併せて耳にすることがあるもう 1 つのワークフローは、より新しいバージョンのアプリケーションへの移行というシナリオです。ArcGIS Enterprise では、一連のアプリケーションを利用できます。これらのアプリケーションは、新しい機能、パフォーマンスの向上、およびユーザーエクスペリエンスの改善を提供するために、時間の経過とともに進化しています。場合によっては、特定のアプリケーションがサポート終了となり、新しい後継アプリケーションに置き換えられることがあり、その際には、サポート終了となるアプリケーションで当初作成されたアイテムを再構築する必要があります。最近の例としては、ArcGIS Enterprise 12.0 以降での ArcGIS Web AppBuilder のサポート終了が挙げられ、これにより ArcGIS Web AppBuilder アプリを ArcGIS Experience Builder へ移行する必要があります。この移行には、各アイテムを個別に再構築することが求められます。このプロセスでは、より新しいアプリケーションへの移行が行われますが、手動による再構築作業がこのプロセスの一部となる可能性があることを考慮し、前述の移行ワークフローとは区別して考えることが重要です。
どの移行ワークフローを計画しているかを理解することは極めて重要です。それによって、プロジェクトに最適なアプローチやツールが明確になるからです。
移行手法の選定
移行の対象となるワークフローを決定したら、次にどのアプローチが最適かを判断する必要があります。ArcGIS Enterprise には、移行に利用できるさまざまなツールが用意されており、各アプローチのメリットや留意点を理解することが重要です。ここでは、移行によく使用されるツールと、それらがどのような状況で最も有用であるかを見ていきましょう。各ツールの概要、想定される移行のユースケース、そのアプローチのメリット、および留意すべき潜在的な制限事項について順を追って説明します。
環境全体の移行に向けたアプローチ
1. WebGISDR
WebGISDR ツールは、災害復旧ツールとして設計されています。このツールを使用すると、Windows および Linux 上の ArcGIS Enterprise 展開全体をバックアップし、そのバックアップを新しい環境に復元することができます。災害復旧ツールとして設計されていますが、状況によっては移行にも活用することを検討できます。このツールでは、ArcGIS Enterprise デプロイメント全体をバックアップおよび復元できるため、新しいインフラストラクチャへの完全な移行を行う場合に適しています。
メリット：このツールは、コンテンツ、ユーザー、構成など、デプロイメント内のすべてをバックアップできます。新しいインフラストラクチャへの移行の場合、これにより、以前の環境から新しいインフラストラクチャへ、すべてのデータを単一のプロセスで移行することが保証されます。
考慮事項：WebGISDR によるアプローチは、デプロイメントの一部のみを移行したいシナリオでは、手間がかかりすぎる可能性があります。
WebGISDR は、特定の完全なデプロイメント移行でのみ使用できます。移行は、同じオペレーティングシステムおよび同じバージョンを使用している別の ArcGIS Enterprise デプロイメント間で行われる必要があります。また、このツールは Windows または Linux のデプロイメントオプションでのみサポートされています。
旧環境と新環境の間で DNSエイリアスが一致している必要があり、これを成功させるには追加の作業とITチームとの連携が必要となります。
2. 「サイトの参加」操作
ArcGIS Server および Portal for ArcGIS コンポーネントの「サイトの参加」操作は、通常、高可用性や災害復旧ワークフローの一環として、ArcGIS Server サイトにスタンバイマシンを追加するために使用されます。このアプローチは、コンテンツを損失することなく、またサービスを中断することなく、移行を目的としてデプロイメント内のマシンを置き換えるためにも使用できます。このアプローチは、マシンごとに個別に実施されます。
メリット：このアプローチにより、ダウンタイムを発生させることなくマシンの移行を行うことができます。適切に実施されれば、すべてのコンテンツ、ユーザー、およびサービスが維持されます。
考慮事項：「サイトへの参加 (Join Site)」操作のワークフローでは、ArcGIS Enterprise ポータルおよび ArcGIS Server のコンテンツ ディレクトリを、旧マシンのローカル ドライブから、新マシンがアクセス可能なネットワーク上の共有場所に移動する必要があります。これには、マシン間で共有ストレージが利用可能であることが必要であり、このワークフローは同一データセンター内のマシン間でのみ実行すべきであることを意味します。
「サイトの参加」ワークフローの実行中、旧マシンと新マシンは一時的にマルチマシン構成となるため、両マシンで同じオペレーティングシステムを使用している必要があります。この方法では、異なる展開方法間（例：Windows から Linux へ）の移行には使用できません。
このアプローチでは、一時的に旧マシンと新マシンを並行して稼働させる必要があります。移行の準備をする際は、このアプローチに必要なインフラストラクチャリソースの要件を考慮してください。
展開全体を正常に移行させるためには、さまざまな手動手順を実行する必要があります。また、プロセス中に問題が発生した場合に備え、ArcGIS Enterprise ポータル コンテンツ ディレクトリや ArcGIS Server ディレクトリ、構成ストアなどの重要なディレクトリのバックアップを確保しておくことが重要です。
「サイトへの参加」操作のワークフローは、同じ展開方法および同じバージョンの ArcGIS Enterprise を使用している展開間の移行のみをサポートします。
特定のコンテンツ、ユーザー、またはワークフローの移行に関するアプローチ
１．グループコンテンツのエクスポートとインポート
この機能により、管理者はグループと共有されているアイテムをエクスポートパッケージ（.epk）にエクスポートし、そのパッケージを使用して、同じ組織または異なる組織内のグループにアイテムをインポートすることができます。移行の場合、これはある環境から別の環境へコンテンツを一括で移動するための有用なツールとなります。
メリット： このアプローチにより、ArcGIS Enterprise ポータル上で直接利用できる直感的なユーザー インターフェースを通じて、環境間でコンテンツを効率的に共有できます。
考慮事項:その名称が示す通り、この機能を効果的に活用するには、コンテンツをグループと共有する必要があります。場合によっては、作業に追加の手順が生じる可能性があります。
WebGISDR と同様に、この機能は ArcGIS Enterprise から ArcGIS Enterprise への移行でのみ利用可能であり、ArcGIS Online との間でコンテンツを移行する際には使用できません。
一部のコンテンツタイプは、この機能ではサポートされていません。ホスト型コンテンツのみがサポートされるため、アイテムが登録済みデータストアを参照している場合は、この機能には適しません。また、ダッシュボードなどのアイテムタイプは、ArcGIS Enterprise 12.1 およびそれ以前のバージョンではサポートされていません。詳細については、製品ドキュメントを参照してください。
２．分散コラボレーション
分散コラボレーションにより、ArcGIS Enterprise 環境間、または ArcGIS Enterprise と ArcGIS Online 組織間で、選択したコンテンツを共有できます。これらの環境は、自社や組織内のものでもよいですし、信頼できるパートナーと外部でコンテンツを共有するために使用することもできます。分散コラボレーションの一般的なユースケースとしては、繰り返されるコンテンツ移行ワークフローや、ArcGIS Enterprise と ArcGIS Online 間のコンテンツ移行が挙げられます。
メリット：分散コラボレーションは、コンテンツを共有するための組織間の信頼関係を確立します。分散コラボレーションの初期設定が完了すると、この確立された信頼関係を通じて、選択したアイテムの共有が容易になります。この確立された信頼関係により、コンテンツを定期的に共有できるため、反復的な移行ワークフローにおいて有用な選択肢となります。分散コラボレーションは、ホストされたコンテンツだけでなく、登録済みデータストアを参照するコンテンツの共有もサポートしています。
考慮事項：分散コラボレーションの初期設定は、信頼関係を確立するために環境間でやり取りを行う、複数のステップからなるワークフローです。このアプローチは、コンテンツを継続的に利用可能にする必要がある反復的な移行プロセスに最も適しています。また、分散コラボレーションには、移行に対応するアイテムの種類やアイテムのサイズ制限といった制約もあります。
３．ArcGIS API for Python を使用したスクリプトによる移行
ArcGIS API for Python は、ArcGIS Enterprise ユーザー向けのさまざまなアクティビティをサポートできる強力な Python ライブラリです。一般的なユースケースの一つとして、ArcGIS API for Python を使用した移行ワークフローのスクリプト化が挙げられ、これは環境間でコンテンツを移動させる際に効果的です。
メリット： ArcGIS API for Python を使用して移行できるホスト型アイテムの種類や、コンテンツを移行できる環境間の制限は最小限です。ArcGIS Enterprise 環境から ArcGIS Online へ、あるいは ArcGIS Enterprise の異なる展開方法間でもコンテンツを移行できます。スクリプト化されたワークフローは、コンテンツの定期的な移行を自動化できるため、繰り返される移行作業にも有益です。
考慮事項：ArcGIS API for Python を通じて移行できるサービスの種類には制限があります。このアプローチは、ホストされたコンテンツ、特に ArcGIS Enterprise と ArcGIS Online 間の移行シナリオに最適です。
スクリプトによる移行には、ArcGIS API for Python に関する専門知識も必要です。スクリプトを最初に作成する際だけでなく、環境、コンテンツ、またはビジネスニーズの変化に応じてスクリプトを長期的に維持管理するためにも、専門知識が求められます。これらのスクリプトを社内で作成・サポートできるか、それともこの作業を外部リソースに依存する必要があるかを把握しておくことが重要です。
既存の移行ツールを使用する代わりに再構築を行う
再構築は、移行に代わるアプローチの一つです。この場合、既存のアイテムや設定を移行する代わりに、コンテンツや環境を再構築することを選択します。このアプローチは、新しい環境で一から始めたい場合や、肥大化している可能性のあるコンテンツや設定を整理したい場合に採用できます。また、ソフトウェアの新バージョンで既存のコンテンツタイプが廃止され、最新の機能を用いて新しい代替手段を構築する必要がある場合にも再構築が必要になる可能性があります。
- メリット：再構築は、新しい環境やコンテンツを意図的に定義する機会を提供します。このアプローチにより、複雑になりがちな既存の設定を見直したり、新しい環境では不要となる可能性のあるコンテンツを削除したりすることができます。また、ゼロから再構築する場合、コンテンツの種類や設定オプションに制限はありません。
- 考慮事項：再構築には時間がかかり、以前の設定や公開ワークフローを繰り返し行う必要がある場合があります。再構築は、繰り返しの移行作業ではなく、1 回限りの移行において検討すべき選択肢です。最後に、再構築のプロセスには、既存の環境やコンテンツの徹底的な棚卸しと理解を含める必要があります。これにより、新しいコンテンツや環境の設定に関わる作業の全範囲を確実に把握できるようになります。
適切な方法を選択するために確認すべき事項
さまざまな移行オプション、その一般的なユースケース、メリットと制限について理解できたところで、ご自身の状況に最適な移行アプローチを見極めるために検討すべき、よくある質問について考えてみましょう。
・これは環境全体の移行なのか、それともコンテンツのみの移行なのか？：これは、移行の範囲を決定するための極めて重要な最初の質問です。環境全体の移行を行う場合、WebGISDR ツールのようなツールが適切なアプローチとなる可能性が高いでしょう。これは、新しい環境に復元するための単一のバックアップを提供してくれるからです。「サイト結合（Join Site）」操作でも環境全体の移行は可能ですが、マシンごとの移行プロセスにおいて追加の手動作業が必要となります。コンテンツの移行の場合は、グループのエクスポート／インポート、スクリプトによるワークフロー、分散コラボレーションなど、有効な選択肢がさらに多くあります。
・これは繰り返し行われるプロセスか、それとも1回限りのプロジェクトか： 1回限りのプロジェクトでは、繰り返し行われる移行ワークフローとは異なるアプローチが必要になる場合があります。1回限りのプロジェクトの場合、移行手法に加えて、環境の再構築も検討すべき選択肢となるでしょう。繰り返し行われる移行プロセスでは、グループコンテンツのエクスポートおよびインポート、分散コラボレーション、ArcGIS API for Python を使用したスクリプト作成などのツールが有効です。
・異なる製品（ArcGIS Enterprise と ArcGIS Online）間で移行するのでしょうか： まったく新しい製品へ移行する場合は、移行の範囲に応じて多面的なアプローチが必要になる可能性があります。環境全体の移行の場合は、コンテンツの移行に分散コラボレーションの利用を検討してください。ユーザー、権限、ライセンス、および構成については、新しい環境で再構築が必要になる可能性が高いです。また、このアプローチに必要な専門知識を持つリソースがある場合は、移行の特定の側面で ArcGIS API for Python の使用を検討することもできます。
・異なるデプロイメントオプション（Windows、Linux、Kubernetes）間で移行しますか？：デプロイメント方法によって、システム要件や構成に微妙な違いがあります。あるデプロイメントオプションから別のものへ移行するための単一のアプローチは存在しません。この場合、再構築が適切なアプローチとなる可能性があります。この作業には多大なリソースを要する場合があるため、スコープを適切に設定してください。
・どのような種類のコンテンツを移行したいですか？：移行オプションによって、アイテムタイプに関する制限が異なります。WebGISDR のようなアプローチでは、サポートされるアイテムタイプに関する制限はほとんどありませんが、分散コラボレーションやグループコンテンツのエクスポート・インポートでは、アイテムタイプやアイテムサイズに関してより多くの考慮事項があります。また、ホストされているコンテンツと参照されているコンテンツのどちらを移行するかも検討する必要があります。参照されているコンテンツの移行には、特定のツールで追加の制限があるためです。特に、この参照されているコンテンツが新しい環境で新たに登録されたデータストアを参照する必要がある場合は注意が必要です。
・このプロジェクトに割り当てられているリソースは？： 移行に必要な労力とリソースのレベルは、移行の範囲、目標、および利用可能な専門知識によって決まります。移行に先立ち、必要なリソースを適切に割り当てられるよう、移行計画、目標、および意図する成果を明確に定義しておいてください。移行によって環境のダウンタイムが生じる可能性があるかどうかを検討し、主要なプロジェクトのスケジュールを考慮して作業計画を立ててください。移行は、ビジネスニーズに応じて、短期間で完了させることも、段階的に実施することも可能です。Esri Professional Services は、移行の計画および作業を通じてお客様をサポートする優れたリソースとなります。さらに、特定の移行シナリオに合わせて特別に設計された Esri ビジネスパートナーのソリューションも用意されており、これらも検討の対象となります。
・再構築と移行、どちらを選ぶべきか？： 移行の範囲と目標を定義した後、移行よりも再構築の方がリソースの消費が少なく、業務への影響も少ないと判断する場合があります。再構築は、次のような場合に検討すべきアプローチです。1 回限りのプロジェクトである場合、環境やコンテンツの構成を最適化したい場合、まったく新しい導入方法や製品に移行する場合、環境がインストールされているマシンや環境で使用されているサードパーティ製ツールをアップグレードしたい場合、そして新しい環境をサポートするためのリソースがある場合です。
一般的な移行シナリオの例と推奨されるアプローチ
このブログで取り上げた内容をまとめて、いくつかの移行シナリオの例と、それぞれに最適な移行アプローチについて見ていきましょう。
１．シナリオ例： 現在、Windows 上で ArcGIS Enterprise 12.1 を展開しています。既存の ArcGIS Enterprise 展開全体を新しいインフラストラクチャに移行したいと考えています。新しいマシンは新しい OS バージョンを搭載しますが、OS は Windows、ArcGIS Enterprise のバージョンは 12.1 のまま維持します。
• 推奨される移行アプローチ： WebGISDR ツールを使用すれば、1回のバックアップで ArcGIS Enterprise の展開全体を移行できます。同じオペレーティングシステム（Windows）および同じバージョンの ArcGIS Enterprise を使い続けるため、これが最もシンプルな移行アプローチとなります。「サイトの結合（Join Site）」操作の使用も検討できますが、その場合はマシンの移行を実現するために、より多くの手動手順が必要になります。
２．シナリオ例： 私の組織には、業務にGISを活用するさまざまなチームがあり、各チームには専用の ArcGIS Enterprise 環境が配備されています。業務上の変更に伴い、私のチームはプロジェクトを別のチームに引き継ぐことになり、そのプロジェクトのコンテンツを、私たちの ArcGIS Enterprise から新しいチームの環境へ移行する必要があります。コンテンツはすべて ArcGIS Enterprise 内でホストされています。
• 推奨される移行アプローチ：この作業には、「グループ コンテンツのエクスポートとインポート」または「分散コラボレーション」という 2 つの主要なツールを検討しています。どちらの方法でも、私のチームの ArcGIS Enterprise から新しいチームの ArcGIS Enterprise へコンテンツを移行できます。現在、すべてのコンテンツは私の ArcGIS Enterprise 内にホストされており、登録済みデータストアを参照していないため、「グループ コンテンツのエクスポートとインポート」を使用することにしました。現時点では、2つのチームの ArcGIS Enterprise 環境間で分散コラボレーションが設定されていないため、このケースでは分散コラボレーションを利用するにはもう少し設定が必要だったでしょう。もし、登録済みデータストアを参照するコンテンツを移行していた場合、グループコンテンツのエクスポートおよびインポートでは参照されたコンテンツがサポートされていないため、分散コラボレーションを使用する必要があったでしょう。
３．シナリオ例： 私は組織のために、開発、テスト、本番の3つの ArcGIS Enterprise 環境を管理しています。私は定期的に、これら 3 つの階層間でコンテンツを昇格または移行したいと考えています。このコンテンツは、ホストされたコンテンツである場合もあれば、登録済みデータストアを参照するコンテンツである場合もあります。私は環境間で分散コラボレーションを設定済みです。
• 推奨される移行アプローチ： 組織で分散コラボレーションが設定されているため、ホストされたコンテンツと登録済みデータストアを参照するコンテンツの両方を移行する必要がある可能性があることを踏まえ、この移行オプションを選択します。時折、ダッシュボードなど、分散コラボレーションではサポートされていない項目があります。そのような場合は、別の環境でダッシュボードを手動で再構築します。ArcGIS API for Python の専門家である新しいチームメンバーが加わる予定であるため、将来的には、こうした繰り返し行われるコンテンツ移行ワークフローの一部をスクリプト化することを検討するかもしれませんが、そのアプローチを検討する前に、スクリプト化されたワークフローを構築・維持するための適切なリソースがチーム内に確保されていることを確認したいと考えています。
４．シナリオ例： 現在、私の組織では ArcGIS Online を使用していますが、ビジネス上のニーズが変化したため、ワークフローとコンテンツの大部分を ArcGIS Enterprise に移行することを決定しました。ArcGIS Enterprise 12.1 をインストールする予定であり、新しい環境には多くのユーザーとコンテンツの大部分を移行する必要があります。私のチームには、ArcGIS API for Python の使用に精通したメンバーがいません。
• 推奨される移行アプローチ：ArcGIS Enterprise と ArcGIS Online は異なる製品であるため、ArcGIS Enterprise が ArcGIS Online 組織の完全な複製にはならないことを踏まえ、この機会を利用して、どのユーザーとコンテンツを本当に移行する必要があるかを検討します。また、この機会を活かして、古いコンテンツを整理し、システムを積極的に利用しているメンバーを見極めることも検討します。新しい ArcGIS Enterprise 環境に移行したいユーザーとコンテンツの範囲を特定した後、まず ArcGIS Enterprise にユーザーを追加することから始めます。既存の ArcGIS Online ユーザーの一部を移行することになるため、各ユーザーに適切なライセンスと権限を確実に付与できるよう、手動で追加することを選択します。コンテンツについては、分散コラボレーション機能を使用して、既存の ArcGIS Online 組織と新しい ArcGIS Enterprise の間でコンテンツを共有することを検討しています。分散コラボレーション機能を使用すれば多くのコンテンツを移行できますが、私が使用している ArcGIS Enterprise 12.1 では、ダッシュボードなど、移行したいアイテムのすべてがサポートされていない可能性があります。そのようなアイテムについては、ArcGIS Enterprise 上で再構築することになります。この作業には ArcGIS API for Python の利用も検討できたが、チーム内にこの技術の専門家がおらず、スクリプトによるアプローチは通常、私のような 1 回限りの移行ではなく、反復的なワークフローに適している。
５．シナリオ例： 私の組織では、デフォルトのオペレーティングシステムを Windows から Linux へ移行することを決定した。現在、私の ArcGIS Enterprise は Windows 上で展開されており、これを Linux マシンへ移行する任務が私に課せられている。
• 推奨される移行アプローチ： 現在のデプロイメント全体を Windows から Linux へ移行できるツールは存在しません。新しいマシンに Linux 環境を構築し、ユーザー、コンテンツ、設定を新しい環境に移行する必要があります。ユーザーは手動で追加し、特定のコンテンツの移行については分散コラボレーションなどの選択肢を検討します。場合によっては、コンテンツを手動で再公開または再構築する必要があるかもしれません。これは大規模な移行となるため、十分な余裕を持って計画を立て、Windows 上の既存環境がユーザーが業務を遂行できる状態で稼働している間に、新しい Linux 環境を構築できるようにします。また、この機会を利用して、すべてのコンテンツとユーザーを移行する必要があるのか、あるいは古いコンテンツや非アクティブなユーザーを整理する好機となるのかを検討する予定です。
移行の時期が来ました！
このブログを通じて、ArcGIS Enterprise ユーザーとして検討しうるさまざまな移行の種類、さまざまな移行アプローチとその留意点、そして移行の準備として自問すべき重要な質問について学んできました。これで、次の移行に取り組む準備が整いました！Esri Community を通じて、次回の移行に向けて皆様をさらに支援できるよう、ご意見をお聞かせください。