サービスに依存する前に移行可能性を検証する

何を使い続けられる必要があるかを定義する

ソースコードを所有することには価値があります。ただし、移行計画の一部にすぎません。

ソースが会社のリポジトリにある、架空のアプリケーションを考えます。ビルドは、サプライヤーから非公開のパッケージをダウンロードします。本番環境は、サプライヤー所有のクラウドアカウントを使っています。データベースの復元手順は、誰も記録していません。

会社はコードを持っていますが、まだサービスを独立して運用できません。移行計画では、権利、資産、アクセス、知識を一緒に扱う必要があります。

依存関係を棚卸しする

エクスポートの形式と範囲を確認します。読める文書をエクスポートできても、すべての関係、添付ファイル、実行記録が保たれるとは限りません。サンプルを求め、実際に使う人と一緒に確認します。

独立した再ビルドを実施する

安全なテスト環境と、承認されたサンプルデータを使います。権限を持つエンジニアに、提案された引き継ぎ一式を渡します。アプリケーションをビルドし、設定を適用し、データを復元し、一つの業務操作を最初から最後まで検証するよう依頼します。

不足する各項目と、入手にかかる時間を記録します。演習中に、文書化されていない知識を黙って補わないでください。目的は、次のチームに何が不足するかを見つけることです。

次に、移行の制約を調べます。サブスクリプションの重複期間、データ転送時間、パッケージへのアクセス、IDの変更、サポートの利用可能性などです。これらの費用を、自社構築と購入の比較に含めます。

エクスポートと削除を分ける

エクスポートはコピーを作ります。移行は、サービスを運用する主体を変えます。削除は、合意した手順に従って指定されたレコードを消します。これらは別々の判断であり、必要な証拠も異なります。

関連する責任者と、必要な保持期間と削除範囲を定義します。サプライヤーの現行の条件と手順を確認します。移行先のシステムを検証する前に、唯一利用できる復旧用コピーを削除しないでください。

Taigaは、管理者によるエクスポート手順と、それとは別の消去手順を文書化しています。シークレットの値は、エクスポートから除外されます。そのため、引き継ぎには、必要なシークレットを権限のある方法で再作成する手段が必要です。現在のエクスポート内容を、移行の要件に照らして検証してください。アプリケーション全体のバックアップだと考えないでください。

許容できる依存関係を判断する

ポータビリティのために、すべてのマネージドサービスを排除する必要はありません。価値、制約、移行経路を理解していれば、依存関係は合理的な選択になり得ます。

受け入れた依存関係、担当者、見直しの条件を記録します。アーキテクチャや契約に大きな変更があった後は、移行演習を繰り返します。続いて、これらの責任を最初から含める導入計画を学んでください。