Authlete 3.0 へのアップグレードは、稼働中の Authlete 2.x インスタンスに対して直接行うことはできません。代わりに、新しい Authlete 3.0 環境を作成し、すべてのサービスとクライアントをその環境へ移行します。サービスとクライアントの移行にあわせて、トークン移行ツールでアクセストークンを移行することもできます。トークン移行ツールは、Authlete 2.2/2.3 環境から Authlete 3.0 環境へトークンを移行するために新たに導入されたサービスです。詳細は「Authlete 3.0 へのトークンの移行」を参照してください。

Configuration Migrator による移行（専用クラウド環境・セルフマネージド環境）

Configuration Migrator のダウンロード

以下の手順 1〜4 は、移行先環境ではなく Authlete の共有クラウド環境（console.authlete.com）で行います。ここで作成する組織とトークンはイメージの取得にのみ使用し、後述の「準備」セクションで用意する移行先環境の認証情報とは別のものです。

Authlete のレジストリからコンテナーイメージを取得するには、次の手順を実行します。

1. 組織の作成

Authlete 管理コンソールにログインします。
自社用の組織を作成します。
「組織ID」を控えておきます。

組織の作成画面

2. アクセスの申請

「組織ID」と「組織名」を Authlete サポートに伝えます。
Authlete が、その組織にレジストリへのアクセスを許可します。

3. レジストリ用トークンの作成

Authlete 管理コンソールで、「読み取り専用」の権限プリセットを選択して組織のトークンを作成します。
このトークンは docker login にのみ使用します。Configuration Migrator の V3_ORG_ACCESS_TOKEN 環境変数には使用しないでください。
認証に使用するため、「組織ID」とトークンを手元に控えておきます。

組織アクセストークンセクション

トークンの作成ダイアログ

4. 認証とイメージの取得

「組織ID」とレジストリ用トークンを使用して Authlete のレジストリにログインし、イメージを取得します。

# Authenticate to Authlete registry
docker login artifacts.authlete.com -u "${SHARED_ORGANIZATION_ID}" -p "${SHARED_ORGANIZATION_ACCESS_TOKEN}"

# Pull the image
docker pull artifacts.authlete.com/configuration-migrator:1.1

準備

サービスとクライアントの設定の移行を始めるには、稼働中の 2.2/2.3 移行元環境と、別に稼働している Authlete 3.0 移行先環境が必要です。以下の各値は、項目ごとに示す環境変数として Configuration Migrator に設定します（「移行の設定」を参照してください）。 2.2/2.3 移行元環境から、次の情報を用意します。

環境の API URL（例: https://api.source-environment）: V2_API_URL 環境変数で使用します
サービスオーナーの「API キー」（サービスオーナーコンソールの「アカウント情報」ページに表示されます）: V2_SO_API_KEY 環境変数で使用します
サービスオーナーの「API シークレット」（サービスオーナーコンソールの「アカウント情報」ページに表示されます）: V2_SO_API_SECRET 環境変数で使用します

サイドメニューの「アカウント情報」と「API キー」「API シークレット」を強調表示したサービスオーナーコンソールの「アカウント情報」ページ（値はマスク済み）

サービスオーナーコンソールの「アカウント情報」ページ 3.0 移行先環境から、次の情報を用意します。

環境の API URL（例: https://api.destination-environment）: V3_API_URL 環境変数で使用します
サービスとクライアントのインポート先となる API サーバーの ID と、作成先となる組織の ID: それぞれ V3_API_SERVER_ID, V3_ORG_ID 環境変数で使用します
- コンソールのナビゲーションバーにあるクラスターのドロップダウンでクラスターを選択します。表示されたページの「クラスター情報」にある「クラスターID」が API サーバーの ID、「組織概要」にある「組織ID」が組織の ID です
API サーバーの ID（「クラスターID」）と組織の ID（「組織ID」）
IdP の URL（例: https://login.destination-environment）: V3_IDP_URL 環境変数で使用します
サービスとクライアントの作成先となる組織の組織アクセストークン: V3_ORG_ACCESS_TOKEN 環境変数で使用します
- 3.0 移行先環境のコンソールの「組織設定」ページの「一般」タブで発行できます。create_service と modify_service の権限を付与して作成する必要があります
- イメージの取得に使用するレジストリ用トークンとは別のトークンです
移行先環境の組織アクセストークン

動的に登録されたクライアントを移行するための前提条件

動的に登録されたクライアント（RFC 7591）を移行する場合は、動的に登録されたクライアント用の移行エンドポイントを利用できるように、各環境に次のバージョンをデプロイし、対応する機能フラグを有効にする必要があります。専用クラウド環境の場合は、Authlete サポートに連絡し、これらの機能の有効化を依頼してください。セルフマネージド環境の場合は、利用者がこれらのバージョンをデプロイし、機能フラグを有効にします。

2.2 の移行元環境: バージョン 2.2.65+ をデプロイし、機能フラグ DCR_RAT_ENDPOINT を有効にする必要があります
2.3 の移行元環境: LTS バージョン 2.3.51+ をデプロイし、機能フラグ DCR_RAT_ENDPOINT を有効にする必要があります
3.0 の移行先環境: バージョン 3.0.36+ をデプロイし、機能フラグ MIGRATE_CLIENT_DCR_ENDPOINT を有効にする必要があります

Configuration Migrator の動作

configuration-migrator は、実行時に次の処理を行います。

2.2/2.3 移行元環境からサービスとクライアントを取得します
各サービスについて、そのサービスがすでに存在するかを確認し、存在しない場合は IdP を介して 3.0 環境にサービスを作成します
サービス内の各クライアントについて、そのクライアントがすでに存在するかを確認し、存在しない場合は 3.0 環境にクライアントを作成します
（クライアントシークレットの移行が有効な場合）クライアントを新規作成したかどうかにかかわらず、クライアントシークレットを確認して揃え、3.0 環境を 2.2/2.3 移行元環境のクライアントシークレットの値で更新します
（動的に登録されたクライアントの移行が有効で、移行元のクライアントが動的に登録されたクライアントである場合）対応する移行先のクライアントがまだ動的に登録されたクライアントとして設定されていなければ、そのクライアントの設定を確定し、2.2/2.3 移行元のクライアントの登録アクセストークン（registration_access_token）を設定します
（クライアントの削除が有効な場合）2.2/2.3 移行元環境に存在しなくなった移行先のクライアントを削除します

デフォルトでは、configuration-migrator は 1 回実行して終了します。移行先環境にすでに存在するサービスとクライアントは再作成しませんが、既存のクライアントについてもクライアントシークレットと動的クライアント登録の設定は揃えます（手順 4・5）。既存のサービスとクライアントのその他の設定は更新しません。

移行の設定

3.0 移行先環境が稼働したら、configuration-migrator を使用して、サービスとクライアントの設定を 2.2/2.3 移行元環境から 3.0 移行先環境へ移せます。動的に登録されたクライアントを移行する場合は、事前に「動的に登録されたクライアントを移行するための前提条件」に示すバージョンの Authlete をデプロイし、機能フラグを有効にしておきます。 configuration-migrator はこの移行をすべて Authlete の API を通じて行います。そのため、サービスとクライアントの設定を移行するには、各環境のエンドポイントと API 認証情報が必要です。

設定項目

必須の設定

環境変数	型	説明
`V2_API_URL`	URL	2.2/2.3 移行元環境の `server` のベース URL です。
`V2_SO_API_KEY`	String	2.2/2.3 移行元環境のサービスオーナーの「API キー」です。サービスオーナーコンソールの「アカウント情報」ページに表示されます。
`V2_SO_API_SECRET`	String	2.2/2.3 移行元環境のサービスオーナーの「API シークレット」です。サービスオーナーコンソールの「アカウント情報」ページに表示されます。
`V3_API_URL`	URL	3.0 移行先環境の `server` のベース URL です。
`V3_API_SERVER_ID`	Number	サービスとクライアントのインポート先となる API サーバーの ID です。
`V3_IDP_URL`	URL	3.0 移行先環境の IdP のベース URL です。
`V3_ORG_ACCESS_TOKEN`	String	移行するサービスとクライアントの作成先となる組織の組織アクセストークンです。
`V3_ORG_ID`	Number	移行するサービスとクライアントの作成先となる組織の組織 ID です。

任意の設定

環境変数	型	説明	デフォルト値
`DRY_RUN`	Boolean	`configuration-migrator` をドライランモードで実行するかどうかを指定します。ドライランモードでは API による取得処理のみを行い、サービスやクライアントの新規作成、クライアントシークレットの更新、クライアントの削除は行いません。ドライランモードを無効にしたときに `configuration-migrator` が実行する処理を把握できるよう、予定しているすべての処理をログに出力します。	false
`SYNC_CLIENT_TOKENS`	Boolean	新たにインポートしたクライアントの `inScopeForTokenMigration` プロパティを `true` に設定するかどうかを指定します。有効にすると、トークン移行ツールが稼働している場合に、これらのクライアントのトークン移行を開始できます。3.0 移行先環境のクライアントでこのフラグが有効になっていることはトークン移行の前提条件であるため、トークンを移行しない場合を除き、有効のままにすることを推奨します。	true
`MIGRATE_CLIENT_SECRETS`	Boolean	クライアントシークレットを移行するかどうかを指定します。有効にすると、3.0 移行先環境のクライアントシークレットを、2.2/2.3 移行元環境のクライアントシークレットと一致するように更新します。クライアントシークレットが一致していることはトークン移行の前提条件であるため、トークンを移行しない場合を除き、有効のままにすることを推奨します。	true
`MIGRATE_DCR_CLIENTS`	Boolean	移行元の API から、動的に登録されたクライアントを移行先環境へ移行するかどうかを指定します。有効にすると、新たに作成した移行先のクライアントに登録アクセストークン（`registration_access_token`）のハッシュを設定します。無効にすると、動的に登録されたクライアントはスキップされ、移行先環境には作成されません。	true
`SERVICE_IDS`	Number[]	サービス ID のカンマ区切りリストです（例: `12345,67891`）。このリストに含まれる ID のサービスと、そのサービスに属するクライアントのみを移行対象とします。空の場合は、指定したサービスオーナーアカウント配下にある 2.2/2.3 移行元環境のすべてのサービスを移行します。	[]
`MAX_V2_RPS`	Number	移行の際に、`configuration-migrator` が 2.2/2.3 移行元の API に送信するリクエストの 1 秒あたりの最大数（RPS）です。2.2/2.3 の API への送信リクエストはすべてこの上限を超えません。	5.0
`MAX_V3_RPS`	Number	移行の際に、`configuration-migrator` が 3.0 移行先の API に送信するリクエストの 1 秒あたりの最大数（RPS）です。3.0 の API への送信リクエストはすべてこの上限を超えません。	5.0
`RETRY_MAX`	Number	エンドポイントごとの最大リトライ回数です。	5
`RETRY_BASE_DELAY`	Number	各リトライ間のバックオフ時間の計算に使用する基準の待ち時間です。単位は秒です。	1.0
`OUTPUT_DIR`	String (Path)	移行サマリーの出力ディレクトリーです。コンテナー内の `/app/migration-output` にマッピングされます。	”./migration-output”
`CONTINUOUS_SYNC`	Boolean	停止されるまで移行をループで繰り返すかどうかを指定します。有効にすると、サイクルごとに新しいサービスとクライアントを作成し、クライアントシークレットと動的クライアント登録の設定を確認します。無効にすると、1 回実行して終了します。	false
`SYNC_CLIENT_DELETION`	Boolean	移行元環境に存在しない移行先環境のクライアントを削除するかどうかを指定します。削除の対象には、移行先環境で直接作成されたクライアントも含まれます。	false
`SYNC_INTERVAL_SECONDS`	Number	同期サイクル間の待ち時間です。単位は秒です。`CONTINUOUS_SYNC` が有効な場合にのみ適用されます。	5
`CLIENT_LIST_REQUEST_COUNT`	Number	移行元と移行先のクライアント一覧 API に、1 ページあたりに要求するクライアント数です。環境のクライアント一覧 API が 1 ページで返す最大件数を別の値に設定している場合にのみ変更します。	100

CONTINUOUS_SYNC を有効にすると、configuration-migrator は「Configuration Migrator の動作」の手順 1〜6 をループで繰り返し、サイクル間に SYNC_INTERVAL_SECONDS 秒待機します。各サイクルで作成するのは移行元環境に新たに追加されたサービスとクライアントのみで、既存のクライアントについては、シークレットと動的クライアント登録の設定が正しく構成されているかを確認します（対応する設定が有効な場合）。SYNC_CLIENT_DELETION が有効な場合は、移行元環境に存在しなくなった移行先のクライアントも各サイクルで削除します。コンテナーを停止するまで動作し続けます（「移行の実行」を参照してください）。

CONTINUOUS_SYNC, SYNC_CLIENT_DELETION, SYNC_INTERVAL_SECONDS, CLIENT_LIST_REQUEST_COUNT は configuration-migrator 1.1 以降で利用できます。

移行手順

まずドライランモードで移行を実行して想定どおりの変更内容であることを確認し、その後ドライランモードを無効にして再度実行し、移行を行うことを推奨します。

無停止（並行切り替え）の方式を使用する場合は、手順 4 で移行を実行する前に認可サーバーの変更をデプロイしてください。

1. 環境の構築と稼働の確認

2.2/2.3 移行元環境と 3.0 移行先環境の API に、configuration-migrator の実行環境からアクセスできることを確認します。

2. Configuration Migrator の設定

前述の表を参照し、正しいエンドポイント、認証情報、サービス ID・組織 ID などの適切なプロパティを configuration-migrator に設定します。ドライランを有効にした（DRY_RUN=true）Docker Compose 設定のサンプルを次に示します。ドライランモードでは、configuration-migrator は両方の環境から読み取りを行い、実行予定の処理をログに出力しますが、作成や書き込みの処理は行いません。サンプルでは、各設定を同じ名前の環境変数（V2_API_URL, V3_ORG_ACCESS_TOKEN など）から読み取ります。実行前に、シェルまたは Compose ファイルと同じディレクトリーの .env ファイルでこれらを設定してください。

name: configuration-migrator-sample
services:
  configuration-migrator:
    image: artifacts.authlete.com/configuration-migrator:1.1
    volumes:
      - ./migration-output:/app/migration-output
    environment:
      # API / required configuration
      - V2_API_URL=${V2_API_URL} # e.g. https://api.source-environment
      - V2_SO_API_KEY=${V2_SO_API_KEY}
      - V2_SO_API_SECRET=${V2_SO_API_SECRET}
      - V3_API_URL=${V3_API_URL} # e.g. https://api.destination-environment
      - V3_API_SERVER_ID=${V3_API_SERVER_ID}
      - V3_ORG_ID=${V3_ORG_ID}
      - V3_ORG_ACCESS_TOKEN=${V3_ORG_ACCESS_TOKEN}
      - V3_IDP_URL=${V3_IDP_URL}

      # Migration Options
      - DRY_RUN=true

      # - SERVICE_IDS=${SERVICE_IDS} # Un-comment and set service IDs (e.g. 12345,67891) if you do not wish to migrate all services available to the service owner

      # Continuous Sync Options
      # - CONTINUOUS_SYNC=true # Un-comment to keep synchronizing services and clients until the migrator is stopped
      # - SYNC_INTERVAL_SECONDS=5 # Seconds to wait between synchronization cycles when continuous sync is enabled

マウントした volumes のディレクトリーには、サマリーファイルが出力されます。コンテナーは UID 1000 で動作するため、ホスト側のディレクトリーにはこのユーザーが書き込める権限が必要です。

SYNC_CLIENT_DELETION が有効（true）な場合、configuration-migrator は移行元環境に存在しないクライアントを移行先環境から削除します。削除の対象には、移行元から移行されたものではなく、移行先環境で直接作成されたクライアントも含まれます。削除は、継続同期モードだけでなく 1 回限りの実行でも行われます。本番の移行で有効にする前に、手順 3 のドライランで削除されるクライアントを確認してください。

3. ドライランモードでの実行

DRY_RUN=true で configuration-migrator を実行し、ログ出力を保存します。

docker compose up 2>&1 | tee dry-run-migration.log

ドライランでは、configuration-migrator が 1 回実行して終了するように、CONTINUOUS_SYNC を無効のままにします。実行が完了したら、ログ出力を確認します。この時点ではサービスとクライアントはまだ移行されていませんが、ドライランを無効にして実行したときに作成・更新・削除される内容がログに出力されています。SYNC_CLIENT_DELETION を有効にする予定の場合は、ドライランでも有効にし、ログの [DRY RUN] Removed destination client … の行を確認してください。この行に、削除される予定のクライアントが列挙されます。

4. 移行の実行

実際の移行を行う準備ができたら、Docker Compose ファイルで DRY_RUN=false を設定し、ログ出力を保存しながら configuration-migrator を再度実行します。

docker compose up 2>&1 | tee migration.log

ドライランを無効にすると、configuration-migrator は移行先環境にサービスとクライアントを作成し、クライアントシークレットを更新します。SYNC_CLIENT_DELETION が有効な場合は、移行元環境に存在しない移行先のクライアントも削除します。 CONTINUOUS_SYNC が有効な場合、configuration-migrator は最初のサイクルの後も終了しません。移行元環境でこれ以上クライアントが登録されないことが確実になった時点で、コンテナーを停止してください（例: docker compose stop）。SYNC_CLIENT_DELETION もあわせて有効にしている場合は、移行先環境でクライアントが登録される前（アプリケーションを 3.0 環境へ切り替える前など）に停止してください。停止しないと、それらのクライアントがサイクルごとに削除されます。停止時に完全なサマリーが出力されます。

5. 結果の確認

移行が正常に完了したことを示す主な指標は、Errors の件数が 0 であることです。 configuration-migrator は実行中に各処理をログに出力し、最後にサービスごとのサマリー、続いて全体のサマリーを出力します。サマリーには、各サービスの状態（serviceStatus）、処理されたサービス数、作成されたクライアント数、更新された動的に登録されたクライアント数、更新されたクライアントシークレット数、および削除されたクライアント数（クライアントの削除が有効な場合）が表示されます。個々のサービスやクライアントのエラーは、サマリーより前のログに出力されます。ネットワークの問題などで configuration-migrator が予期せず停止した場合も、安全に再実行できます。移行先にすでに存在するサービスとクライアントは再作成されず、クライアントシークレットは再度揃えられます。SYNC_CLIENT_DELETION が有効な場合は、再実行時にも、移行元環境に存在しない移行先のクライアントが削除されます。また、移行の成功後に configuration-migrator を再実行して、すべてが正しく移行されたことを確認することもできます。次の出力サンプルは、2 つのサービスについてのサービスごとのサマリーと全体の移行サマリーの例です。

My Service（apiKey=309958490093）
- 新たに作成されたサービス（serviceStatus=created で示されます）
- 合計 1241 件のクライアントが作成・移行された
- 1241 件のうち 612 件は動的に登録されたクライアントであり、動的に登録されたクライアントの移行処理によって追加の更新も正常に行われた
- すべてのクライアントが新規のため、すべてのクライアントシークレットが更新された（Client secrets synced: 1241）
- サービスが新規のため、削除対象となる移行先のクライアントはない（Clients deleted: 0）
Another Service（apiKey=309958490091）
- 既存のサービス（serviceStatus=already_exists）
- このサービスで 121 件の新しいクライアントが検出され、移行先環境へ移行された
- 121 件のうち 5 件は動的に登録されたクライアントであり、動的に登録されたクライアントの移行処理によって追加の更新も正常に行われた
- すべてのクライアントが新規のため、すべてのシークレットが更新された（Client secrets synced: 121）
- 3 件のクライアントは移行先環境に存在するものの移行元環境には存在しないため、削除された（Clients deleted: 3）

全体のサマリーには、処理したサービスとクライアントの合計数と、サービスごとのレポートで記録されたすべてのイベントの合計が含まれます。

2026-09-29 06:56:55 [INFO] ============================================================
2026-09-29 06:56:55 [INFO] Service Summaries
2026-09-29 06:56:55 [INFO] ============================================================
2026-09-29 06:56:55 [INFO] Service name: My Service (apiKey=309958490093) serviceStatus=created overallStatus=OK
2026-09-29 06:56:55 [INFO] ------------------------------------------------------------
2026-09-29 06:56:55 [INFO] Total clients in service: 1241
2026-09-29 06:56:55 [INFO]   Clients created: 1241
2026-09-29 06:56:55 [INFO]   DCR clients updated: 612
2026-09-29 06:56:55 [INFO]   Client secrets synced: 1241
2026-09-29 06:56:55 [INFO] Client deletion sync:
2026-09-29 06:56:55 [INFO]   Clients deleted: 0
2026-09-29 06:56:55 [INFO] Errors: 0
2026-09-29 06:56:55 [INFO] ------------------------------------------------------------
2026-09-29 06:56:55 [INFO] Service name: Another Service (apiKey=309958490091) serviceStatus=already_exists overallStatus=OK
2026-09-29 06:56:55 [INFO] ------------------------------------------------------------
2026-09-29 06:56:55 [INFO] Total clients in service: 121
2026-09-29 06:56:55 [INFO]   Clients created: 121
2026-09-29 06:56:55 [INFO]   DCR clients updated: 5
2026-09-29 06:56:55 [INFO]   Client secrets synced: 121
2026-09-29 06:56:55 [INFO] Client deletion sync:
2026-09-29 06:56:55 [INFO]   Clients deleted: 3
2026-09-29 06:56:55 [INFO] Errors: 0
2026-09-29 06:56:55 [INFO] ------------------------------------------------------------
2026-09-29 06:56:55 [INFO] ============================================================
2026-09-29 06:56:55 [INFO] Migration Summary
2026-09-29 06:56:55 [INFO] ============================================================
2026-09-29 06:56:55 [INFO] ------------------------------------------------------------
2026-09-29 06:56:55 [INFO] Total services processed: 2
2026-09-29 06:56:55 [INFO] Total clients processed: 1362
2026-09-29 06:56:55 [INFO]   Created clients: 1362 (skipped 0, failed 0)
2026-09-29 06:56:55 [INFO]   DCR clients updated: 617/617 created (0 skipped, failed 0)
2026-09-29 06:56:55 [INFO]   Client secrets synced: 1362/1362 (0 skipped, failed 0)
2026-09-29 06:56:55 [INFO] Client deletion sync:
2026-09-29 06:56:55 [INFO]   Clients deleted: 3/3 (0 skipped, failed 0)
2026-09-29 06:56:55 [INFO] Errors: 0
2026-09-29 06:56:55 [INFO] Report saved to /app/migration-output/configuration-migration-report-1790665015.json

CONTINUOUS_SYNC が有効な場合は、各サイクルの終わりに、サービスごとの 1 行のイテレーションサマリーも出力します。コンテナーを停止すると、それまでに実行したすべてのサイクルを対象とする完全なサマリーを出力します。このモードでは、全体の移行サマリーに Iteration count も表示されます。また、各イベントは合計のみが表示され、上記のサンプルにある attempted, skipped, failed の件数は表示されません。イテレーションログの出力サンプルを次に示します。直前のイテレーションで行われた処理のイベント指標が含まれています。

10 件のクライアントを作成し、そのすべてのシークレットを更新。そのうち 5 件は DCR クライアント
同じイテレーション内で 3 件のクライアントを削除

2026-09-29 06:51:11 [INFO] Iteration summary [Another Service (309958490091)]: clients created 10 (skipped=0 failed=0) secrets updated 10 (attempted=10 skipped=0 failed=0) dcr clients configured 5 (attempted=5 skipped=0 failed=0) clients removed 3 (attempted=3 skipped=0 failed=0) errors 0

トークン移行（専用クラウド環境・セルフマネージド環境）

トークンはトークン移行ツールによって別途移行します。「Authlete 3.0 へのトークンの移行」を参照してください。

Authlete 管理コンソールによる移行（共有クラウド環境のみ）

Authlete の共有クラウド環境にあるアカウントを移行する場合は、Authlete 管理コンソールの UI から移行します。一般的なアップグレードの流れは次のとおりです。

新しい Authlete 3.0 環境の Authlete 管理コンソールにログインします
移行に必要な数の組織を作成し、設定します
サービスとクライアントの移行（下記のセクションを参照）: 「データインポート/移行」機能を使用して、該当するサービスとクライアントをこの組織にインポートします
トークン移行: 既存のトークンを新しい 3.0 環境で利用できるようにする必要がある場合のみ実施します
OAuth サーバー / アプリケーションを更新します

無停止（並行切り替え）の方式を使用する場合は、手順 3 の前に認可サーバーの変更をデプロイしてください。

トークン移行ツールは移行元のデータベースに対する読み取りアクセス権のみを持つため、いかなるデータも変更できません。

サービスとクライアントの移行

Authlete 管理コンソールにログインし、「組織設定」>「基本設定」>「データインポート/移行」を開きます
Authlete 2.x のサービスオーナーコンソールにログインし、アカウントのサービスオーナー「API キー」と「API シークレット」をコピーして貼り付けます（「アカウント情報」ページに表示されます）

Authlete 2.x のアカウント情報

利用中のクラスターの Authlete API URL を入力します

次のいずれかの URL を入力します。
- アメリカ: https://api.authlete.com
- 日本: https://tokyo.authlete.com
- ブラジル: https://latam.authlete.com

「続行」をクリックします

サービスの移行フォーム

API から、そのアカウントに紐づくサービスの一覧が返されます
移行するサービスの横にあるチェックボックスを選択します
トークン移行ツールを使用する場合は、「Synchronize Client Tokens」と「Migrate Client Secrets」のチェックボックスを選択します。これにより、サービスに属するクライアントが検出され、そのトークンやシークレットが 3.0 環境へ移行されます。この設定は、インポート後にクライアントごとに「クライアント設定」>「基本設定」>「詳細設定」>「Migration Settings」で更新することもできます。
「クラスターを選択」のドロップダウンをクリックし、サービスの移行先となるクラスターを選択します

サービスの選択

「続行」をクリックします
確認画面で「インポート」をクリックします
Authlete 管理コンソールのナビゲーションに、サービス（と紐づくクライアント）が表示されます

移行の確認

トークン移行（共有クラウド環境）

トークンはトークン移行ツールによって別途移行します。「Authlete 3.0 へのトークンの移行」を参照してください。

Terraform

セルフマネージドデプロイ

オブザーバビリティ

パフォーマンス

既存システムからの移行

ネットワーク

APIゲートウェイとの連携

運用ポリシー

アクセス制御

Authlete 3.0 への設定の移行

Configuration Migrator による移行（専用クラウド環境・セルフマネージド環境）

Configuration Migrator のダウンロード

1. 組織の作成

2. アクセスの申請

3. レジストリ用トークンの作成

4. 認証とイメージの取得

準備

動的に登録されたクライアントを移行するための前提条件

Configuration Migrator の動作

移行の設定

設定項目

必須の設定

任意の設定

移行手順

1. 環境の構築と稼働の確認

2. Configuration Migrator の設定

3. ドライランモードでの実行

4. 移行の実行

5. 結果の確認

トークン移行（専用クラウド環境・セルフマネージド環境）

Authlete 管理コンソールによる移行（共有クラウド環境のみ）

サービスとクライアントの移行

トークン移行（共有クラウド環境）

​Configuration Migrator による移行（専用クラウド環境・セルフマネージド環境）

​Configuration Migrator のダウンロード

​1. 組織の作成

​2. アクセスの申請

​3. レジストリ用トークンの作成

​4. 認証とイメージの取得

​準備

​動的に登録されたクライアントを移行するための前提条件

​Configuration Migrator の動作

​移行の設定

​設定項目

​必須の設定

​任意の設定

​移行手順

​1. 環境の構築と稼働の確認

​2. Configuration Migrator の設定

​3. ドライランモードでの実行

​4. 移行の実行

​5. 結果の確認

​トークン移行（専用クラウド環境・セルフマネージド環境）

​Authlete 管理コンソールによる移行（共有クラウド環境のみ）

​サービスとクライアントの移行

​トークン移行（共有クラウド環境）

Configuration Migrator による移行（専用クラウド環境・セルフマネージド環境）

Configuration Migrator のダウンロード

1. 組織の作成

2. アクセスの申請

3. レジストリ用トークンの作成

4. 認証とイメージの取得

準備

動的に登録されたクライアントを移行するための前提条件

Configuration Migrator の動作

移行の設定

設定項目

必須の設定

任意の設定

移行手順

1. 環境の構築と稼働の確認

2. Configuration Migrator の設定

3. ドライランモードでの実行

4. 移行の実行

5. 結果の確認

トークン移行（専用クラウド環境・セルフマネージド環境）

Authlete 管理コンソールによる移行（共有クラウド環境のみ）

サービスとクライアントの移行

トークン移行（共有クラウド環境）