【UiPath】ラストチャンス！クラシックフォルダーからモダンフォルダーへの移行方法 #1

はじめに

UiPath Orchestratorをお使いの方は、ご存知かと思いますが、Orchestratorの機能である「クラシックフォルダー」がいよいよ廃止されます。
これまで小さな機能の廃止は何度かあったかと思いますが、UiPathにおける主要機能の廃止は、おそらく初めてなのではないでしょうか？何も対策していない場合は、必ず大きな混乱が発生するので、まだ何も対策を考えていない方は、すぐ始めてください！

クラシックフォルダーとモダンフォルダー

Orchestratorにおける「フォルダー」機能とは、プロセス、ジョブ、キュー、アセット、ロボットなどのリソースを分離することができる機能です。例えば、組織・チーム単位にフォルダーを分けることで、それぞれのリソースを分けて管理することができます。
「クラシックフォルダー」は、オンプレ版OCの2019.10に正式にリリースされた機能ですが、それ以前は、「組織単位（Organization Units：OU）」という名称の機能として存在していました。OUはプレビューの位置づけのため、configファイルを修正しないと有効化されない機能でしたので、使用している方は少なかったと思います。

一方、「モダンフォルダー」のリリースも2019.10とクラシックフォルダーと同じタイミングでした。
クラシックとモダンの両方が同じタイミングでリリースされるのであれば、モダンしか使わないと思われがちですが、リリース当時、モダンフォルダーはUnattendedが使用できないなど制約があり、当時はクラシックフォルダーとモダンフォルダーの両立が必要でした。
（クラシック・モダンの両方を使うと管理が面倒なので、クラシックフォルダーに統一していた方も多いかと思います。）

しかしながら、リリースを重ねるごとにモダンフォルダーも進化し、現在（v2022.10）ではモダンフォルダーは機能的に完全にクラシックを追い越しています。

v2019.10時点の機能比較

v2022.10時点の機能比較

廃止までの流れ

UiPathの各製品サービスについて、機能の廃止はドキュメントポータルにて情報が公開されています。

対象の機能は、まず「非推奨」のカテゴリに分類され、しばらくすると「削除」のカテゴリに移行します。
「削除」に分類されると、Automation Cloudならリリース時点で機能が削除されます。
オンプレ版の場合は、バージョンアップをしなければ、対象の機能を使い続けることができますが、バージョンにもサポート期間が設定されているため、サポート外の製品はバージョンアップをすることを推奨します。ということは、オンプレ版OC（v2022.10）の延長サポートは2025年11月14日までなので、ここまではクラシックフォルダーは使用可能です。

2021年10月・・・非推奨の発表
2022年4月 ・・・削除の発表
2022年10月・・・非推奨化
2023年4月 ・・・削除の実施

では、Automation Cloudでは具体的にいつ削除されるのでしょうか？
過去の3年間の4月リリースは、2020年4月2日、2021年4月12日、2022年4月4日なので、4月の最初の1週目くらい（遅くても2週目）になると思われます。

因みに同じ2023年4月のタイミングで「標準マシン」も削除されます。マシンテンプレートに移行しましょう！

削除されるとどうなるのか

Automation Cloudでの4月リリース後は、クラシックフォルダーは読み取り専用となり、編集不可・ロボット接続不可となるらしいです。
データがいつまで残っているかは不明ですが、過去に実行したジョブのログ確認などの目的には使用できそうです。
データが消失したらマズい人は、データをエクスポートしておくことをお勧めします。Orchestrator ManagerでExcel出力できます。

何をやればよいのか

クラシックフォルダーからモダンフォルダーへの移行は、以下のステップにて行います。

使用状況やリスク、態勢に応じで簡略化しても良いと思います

1. 計画・準備
   1. 移行方針・計画の策定
   2. 移行方式・手順の検証
   3. 移行手順書の作成
2. 移行
   1. 移行作業の実施
   2. 移行作業結果の検証

1-1. 移行方針・計画の策定

移行に関する方針や計画を決めます。
移行方針については、移行ツールがあるので、これを使用することをお勧めします。開発環境がある場合は、開発環境で検証した後、本番環境での移行作業に入るのが普通ですが、本番環境しかない場合は、検証用テナントやフォルダーを作って、テストデータで検証します。
スケジュールについては、移行作業のために環境を専有する必要があり、業務利用しているユーザとの調整が必要になる場合があります。業務時間中に移行作業するのか、夜間・休日に対応するかなど、具体的な作業計画を決めていきます。

• スケジュール
• 体制と役割
• 移行対象リソース（ロボット、アセット、キューなどなど）
• 移行方針（ツールを使うのか・使わないのか、検証環境を用意するか・しないか）
• 検証方法（作業結果に対して、どんな検証を実施するのか）
• 移行失敗時の対応

1-2. 移行方式・手順の検証

開発環境やその他の環境を使って、移行に関する手順を検証し、事前にリスクや課題を洗い出します。
移行ツールを使用する場合、手作業での移行（移行ツールが対象外とする箇所）の有無を洗い出します。

1-3. 移行手順書の作成

1-2で実施した検証を元に本番用の手順書を作成します。

2-1. 移行作業の実施

1-3で作成した手順書を元に移行作業を実施します。

移行ツールの使い方については次回の記事で解説します

2-2. 移行作業結果の検証

正しく移行できているかチェックします。

• 移行対象のリソースの突合（件数が合っているか、データの中身が合っているか）
• 移行後のロボットが正しく動作するか

おわりに

次回は移行ツールについて説明します。