ソースをエクスポートしたプロジェクトには可搬性テストが必要

ソースコードをエクスポートできても、受け取ったのはファイルだと証明できるだけです。元のAIアプリビルダーがなくなった後にも、プロジェクトをビルドし、起動し、ユーザーを認証し、本番データを読み取り、デプロイできるとは限りません。可搬性は販売契約のチェック項目ではなく、受入テストとして扱いましょう。

私は生成されたアプリケーションを十分な数だけ引き継いできたので、整ったリポジトリを見てもすぐには信用しません。高くつく失敗は、目に見えるアプリケーションコードの外に隠れがちです。ベンダーサービスへの実行時リクエスト、他社のテナントに登録された認証コールバック、バージョン管理に入っていないデータベースポリシー、管理画面にしか存在しないデプロイ設定などです。エクスポートしたものと、チームが管理するアカウントで利用できる文書化済みの外部サービスから、チーム自身が動作を再現できるときだけ、そのプロジェクトは可搬だと言えます。

ソースをエクスポートしてもビルダーに依存することがある

ソースをエクスポートしたプロジェクトが独立して動くには、必要なビルド時・実行時の依存関係をすべて入手でき、文書化され、移管でき、ビルダー外で使うライセンスを持っている必要があります。これは「リポジトリがコンパイルできる」より厳しい基準です。空のマシンから本番リリースを動かすまでの道筋を対象にし、アイデンティティ、データ、定期処理、シークレット、ネットワークルール、復旧まで含めます。

よく混同される主張は3つあります。ソースへのアクセスはファイルを確認できることです。ビルドの独立性は、ビルダーを呼び出さずに成果物を作れることです。実行時の独立性は、その成果物がビルダーなしで実際のリクエストに応え続けられることです。ベンダーは最初の条件を満たしても、残り2つを満たさない場合があります。

この違いは契約に直接影響します。契約で「ソースエクスポート」が約束されていても、React のディレクトリ、パッケージマニフェスト、README を受け取る一方で、プロプライエタリSDKやホスト型ゲートウェイが必要なことがあります。代わりに運用上の結果を求めましょう。顧客が所有するアカウントを使い、クリーンな環境で、権限を持つエンジニアが受入済みリリースをビルド・実行できることです。

テスト前に境界を定めます。マネージドサービスがあるだけで可搬性に失敗したことにはなりません。多くの本格的なアプリケーションは、クラウド、決済代行、メールプロバイダー、アイデンティティサービスに依存しています。重要なのは、その依存関係を理解したうえで選択し、自社の契約のもとで移行または置き換えられるかです。別途契約できない隠れたベンダーサービスと、自社クラウドアカウント内にある文書化済みのPostgreSQLデータベースは別物です。

外部コンポーネントごとに、所有者、目的、置き換え方法、障害時の動作という4項目を持つ依存関係台帳を作ります。「所有者」とはパスワードを知る人ではなく、法的なアカウント保有者です。「置き換え方法」には、移行手順、再実装できるインターフェース、そのサービスを使い続けるという明示的な判断などがあります。「障害時の動作」には、利用できなくなったときユーザーに何が見えるかを記録します。売り手がこの4項目を埋められないなら、そのエクスポートはリスクを見積もれるほど説明されていません。

最初に行うべきテストは地味です。ビルダーのアカウントへのアクセスを切り、アプリケーションを試してください。ステージングのコピーでトークンを無効化し、ネットワーク境界で既知のドメインを遮断して、何が失敗するかを見ます。最初からすべてのファイルを読む必要はありません。実行時の証拠なら、注入された設定やコンパイル済みパッケージからの呼び出しを含め、コードレビューでは見逃す依存関係を見つけられます。

実際の操作フローを動かしながらアプリを追跡する

代表的な操作フロー中のDNS、外向き接続、ブラウザのリクエスト、バックグラウンドジョブを観察すると、実行時のコールバックが見えてきます。ホームページが読み込めても、ほとんど証明にはなりません。サインイン、パスワード復旧、ファイルアップロード、検索、請求状態の変更、メール配信、定期タスク、管理操作、製品が実際に提供しているAI機能を試してください。

外向き通信を記録する新しいステージングネットワークでアプリケーションを動かします。依存関係台帳に書かれた宛先だけを許可します。環境が対応できるなら、一覧にない通信を拒否するポリシーから始めてください。遮断されたリクエストごとに確認します。それは必須か、任意のテレメトリーか、更新確認か、文書化されていないコントロールプレーンの呼び出しか。

サーバーに届かない依存関係もあるため、ブラウザの開発者ツールは重要です。ストレージを消去し、新しいセッションで使った後に、Networkパネルを確認します。リクエスト先ホスト、失敗したプリフライトリクエスト、WebSocket接続、読み込んだスクリプト、リダイレクトを見ます。サーバーのリポジトリが自己完結して見えても、フロントエンドがビルダーAPIを直接呼び出している場合があります。サービスワーカーも古い動作を残すので、テストを繰り返す前に解除してください。

Unix系のソースツリーでは、次の検索で最初の有用な一覧を作れます。

grep -R -n -E 'https?:|wss?:|fetch[(]|axios|WebSocket|grpc|callback|webhook' .

出力は path/to/file:line:matching text の形になります。パッケージメタデータのドメインは実行時の呼び出しを示すとは限らないため、生成されたロックファイルはアプリケーションコードとは分けて確認します。反対に、検索結果がきれいでも独立性の証明にはなりません。環境変数でホストを組み立てたり、DNSエイリアスで隠したり、バイナリ依存関係が独自のリクエストを出したりするためです。

ベンダー名、SDKのインポート、環境変数の接頭辞をそれぞれ別に検索します。次にロックファイルを確認し、パッケージが公開レジストリから解決されるのか、ベンダーの非公開レジストリから解決されるのかを調べます。キャッシュによる成功は誤解を招きます。隔離したテスト環境の言語パッケージキャッシュを削除し、文書化されたレジストリ認証情報だけで再ビルドしてください。

スケジューラーの境界をまたぐまで、バックグラウンド動作を追跡します。Webプロセスが正常に見えても、キューコンシューマーが失敗し、定期レポートが止まり、Webhookの再試行がたまっているかもしれません。通常の実行時刻を待つとテストが遅くなる場合は、ジョブを手動で起動します。外向き連携ごとに、宛先、リクエスト方式、認証形式、応答の種類、再試行ルール、ユーザーに見える影響を記録します。

「そのコールバックはテレメトリーだけです」という説明を、障害テストなしに受け入れないでください。遮断して、同じ操作フローを繰り返します。任意のテレメトリーなら、すぐにタイムアウトするか、ユーザーの操作を変えずに失敗するべきです。私は、リクエストトランザクション内にログ呼び出しが置かれ、無害な分析サービスの停止が保存失敗に変わる例を見てきました。リスクを決めるのはラベルではなく、コードパスです。

プロプライエタリSDKには削除かライセンスの道筋が必要

プロプライエタリSDKを使えるのは、それを入手でき、ビルドに使え、合法的に実行でき、事業が許容できる期間内に置き換えられる場合だけです。エクスポート内にラッパーのソースがあっても、そのSDK、プロトコル、ホスト型エンドポイント、その背後のモデルを使う権利が得られるわけではありません。

依存関係はマニフェストとソースのインポートの両方から一覧化します。JavaScriptでは package.json とロックファイルを確認します。Goでは go.mod とチェックサムを確認します。Flutterでは pubspec.yaml とロックファイルを確認します。Gitリポジトリ、非公開レジストリ、ローカルパス、アーカイブから取得するパッケージも記録します。こうした場所には、ビルダー所有のコンポーネントが隠れやすいからです。

疑わしいパッケージごとに、具体的に次の4点を確認してください。

1. 新しく用意した顧客所有のビルドエージェントが、正確なバージョンをダウンロードできるか。
2. ビルダーとの契約が終了した後も、そのライセンスで本番利用を許可されるか。
3. そのパッケージは、顧客が直接契約できるサービスを呼び出すか。
4. インターフェースは置き換えられる程度に小さく、テストされているか。

顧客所有の組織で作成した認証情報を使い、コールドビルドを実行します。開発者の設定ディレクトリ全体をテストマシンにコピーしてはいけません。キャッシュ済みパッケージ、暗黙のレジストリ設定、個人用トークンまで持ち込み、テストの目的を損ないます。正しいビルド手順は文書化されたツールチェーンのバージョンから始め、追加の認証情報を1つずつ明示します。

ツールチェーンが対応していればソフトウェア部品表を生成します。ただし、それを可搬性の判定と混同しないでください。SBOMはコンポーネントを一覧にしますが、リモートアカウントを誰が管理しているか、パッケージが外部に通信するかはほとんど分かりません。リポジトリが宣言するものと、ビルド済み成果物に含まれるものを照合するために使います。

プロプライエタリなクライアントが狭いアダプターの背後にあるなら、今のうちにアダプターに対する契約テストを書きます。既知のリクエストを渡し、正規化した応答を検証し、ネットワークエンドポイントを遮断した状態でも同じテストを実行します。失敗は明確で、影響範囲が限られているべきです。プロプライエタリな呼び出しがビューコンポーネント、ルートハンドラー、データモデルの各所にあるなら、契約前にリファクタリング費用を見積もってください。問題の大きさはSDKの行数ではなく、呼び出し箇所の数と意味的な結び付きの強さで決まります。

チームは、購入前にすべてのプロプライエタリな依存関係を置き換えるよう勧めがちです。一見安全ですが、買い手が使い続けるつもりのサービスに何週間も費やすことがあります。利用できない、または契約できない依存関係は取り除き、受け入れるものは分離し、残りには移行コストを付ける方がよいでしょう。可搬性とは外部サービスがゼロのアプリケーションではなく、選択を自分で管理できることです。

認証はソースツリーだけのものではない

認証を円滑に移すには、顧客がアイデンティティテナント、リダイレクト登録、署名鍵、ユーザー識別子、メールテンプレート、復旧手順を管理している必要があります。アプリケーションコードは通常、その仕組みの一部しか表していません。

まず、ログインまでの実際の経路を描きます。ブラウザがアプリケーションに到達し、アプリケーションがアイデンティティプロバイダーへリダイレクトし、プロバイダーが登録済みのコールバックへ戻り、バックエンドが認証情報を交換または検証します。経由点ごとに所有者と設定場所を記録します。ビルダーの組織を通じてしかアクセスできない管理画面があるなら、受入前に移管または置き換えを求めます。

マネージド認証では、扱いにくいデータ問題が特に起きます。アプリケーションのユーザーテーブルには、メールアドレスや内部の永続IDではなく、プロバイダー固有のsubjectが保存されていることがあります。新しいアイデンティティテナントが異なるsubjectを発行するなら、行をエクスポートしても役に立ちません。アカウント照合、重複の扱い、パスワード利用者、ソーシャルログイン利用者、多要素認証の登録、ロックされたアカウント、メールアドレスを変更した利用者をテストします。

OpenID Connectでは、sub クレームは発行者の範囲内でローカルに一意で、再割り当てされない識別子として定義されています。発行者が重要です。sub だけを世界共通で移せるものとして扱うと、テナント変更後に誤ったアプリケーションレコードを結び付けるおそれがあります。発行者とsubjectを保存して比較し、移行時には明示的な対応付けを設計します。

テストには少なくとも4つのアカウントが必要です。通常ユーザー、管理者、無効化されたユーザー、第2認証要素を持つユーザーです。顧客所有のテナントでアイデンティティ設定を移行または再作成し、ステージング用データベースのコピーを復元して、ログイン成功とアクセス拒否を確認します。ログアウト、トークン更新、パスワードリセット、招待の受諾、セッション期限切れもテストしてください。チームは正常なログイン経路を覚えていても、切り替え後に復旧機能の破損を見つけることがあります。

リポジトリから、リダイレクトURI、クライアントID、発行者名、Cookieドメイン、audience値、署名鍵への参照を探します。シークレットはリポジトリに置かず、名前、所有者、作成手順、ローテーション手順、必要な形式はデプロイ文書に記載します。環境ファイルのサンプルは、実際の値を含めずに契約を示すべきです。

AUTH_ISSUER=
AUTH_CLIENT_ID=
AUTH_CLIENT_SECRET=
AUTH_CALLBACK_ORIGIN=
SESSION_SIGNING_KEY=

移行を「後で」できるからといって、共有ビルダーテナントを恒久的な取り決めとして受け入れないでください。アイデンティティの移行は、すべてのアクティブユーザーと認可に関する前提に触れます。契約前に管理権限を移すか、置き換えを費用化し、検証済みの契約条件にしてください。

データベースの可搬性には動作と運用も含まれる

スキーマ、拡張機能、行レベルポリシー、トリガー、オブジェクトストレージ、キュー、バックアップ、接続ルールがデータベースの外にある場合、データベースダンプだけでは不十分です。データベースの可搬性とは、データを復元し、それを保護・変更する動作も再現できることです。

文書化されたメジャーバージョンの、空の顧客所有PostgreSQLインスタンスから始めます。リポジトリのマイグレーションを順に適用します。プロジェクトにマイグレーションがなく、ベンダー作成のスキーマダンプをインポートする必要があるなら、欠陥として記録します。ダンプは今日の状態を捉えることはあっても、次のリリースでその状態を安全に変える方法までは説明しません。

復元したスキーマを本番またはステージングと比較します。テーブル、列、型、制約、インデックス、シーケンス、ビュー、関数、トリガー、有効な拡張機能、ロール、権限、行レベルセキュリティポリシーを確認します。多くのマイグレーションツールはロールやプロバイダーレベルの設定を省きます。復元したロールにシーケンスや関数の権限がないため、基本的な読み取りテストは通っても管理ジョブが失敗することがあります。

次に、制御された往復テストでデータ経路を検証します。

1. 公開されているアプリケーションの操作フローでレコードを作成する。
2. 共有される想定のとき、権限を持つ別のユーザーでそのレコードを読む。
3. 権限のないユーザーが読んだり変更したりできないことを確認する。
4. アプリケーションを通して更新・削除する。
5. 別のクリーンなインスタンスにデータベースを復元し、読み取りを繰り返す。

この手順では、アプリケーションコード、認可ポリシー、生成される値、復旧可能性をまとめて検証できます。SQLで行数を直接数えるだけでは、これらの動作は確認できません。

行がアップロードファイルを指すなら、オブジェクトストレージをデータベース境界の一部として扱います。バケット、オブジェクトメタデータ、アクセスルール、ライフサイクルルール、URL生成設定をエクスポートします。元のファイルがビルダー所有のバケットに残っているなら、オブジェクトキーだけが詰まった復元済みデータベースは役に立ちません。同じ注意は検索インデックスとベクトルストアにも当てはまります。移行するのか再構築するのかを決め、再構築手順を証明してください。

小さなダンプ1つで成功・失敗を判断しないでください。長文、null、ASCII以外の文字、大きなオブジェクト、夏時間の切り替え付近のタイムスタンプ、代表的な関連を含む、ステージング規模のコピーを使います。架空のベンチマークは不要です。許容できる停止時間内に移行が完了し、その後もアプリケーションが動くという証拠が必要です。

バックアップを行っているという主張には、復元が必要です。誰がバックアップをスケジュールするのか、コピーはどこに置かれるのか、誰が復号できるのか、保持期間はどうなっているのか、バックアップ失敗をどう検知するのかを確認します。隔離したアカウントに、文書化された手順で1つ復元します。復元ボタンを押せるのがビルダーだけなら、それは独立した復旧計画ではなくサービス機能です。

CIパイプラインがなければ製品知識も欠けている

再現可能な継続的インテグレーションがないエクスポート済みリポジトリでは、ツールのバージョン、ビルド順、テスト、成果物のパッケージ化、データベース移行のタイミング、リリースの判定基準を、買い手が改めて探り直すことになります。売り手の内部パイプラインをそのまま移せなくても、この知識は納品物の一部です。

パイプライン定義、コンテナのビルドファイル、ツールバージョンのファイル、テストコマンド、lintルール、マイグレーションコマンド、インフラ定義を探します。続いて、実際のデプロイログと照合します。文書には単純なWebビルドと書かれていても、マネージドプラットフォームが裏で設定を生成し、サーバーコンポーネントを注入し、モバイルバンドルを作り、データベースマイグレーションを実行していることがあります。

顧客所有のCIアカウントで、最小限のパイプラインを再構築します。固定したリビジョンをチェックアウトし、宣言されたツールチェーンをインストールし、依存関係を取得し、テストを実行し、不変の成果物を作り、成果物の識別情報を記録する必要があります。テスト中のデプロイは手動のままでも構いませんが、ステージングに届く成果物はパイプラインが作ったものでなければなりません。

簡潔な受入ログは次のような形式にできます。

revision: 4f2c9ab
toolchain: declared versions loaded
dependencies: cold install passed
tests: unit and integration passed
artifacts: web, server, mobile
migrations: dry run passed
staging: health and workflow checks passed

値は異なりますが、各行には人の記憶ではなく、機械出力またはリンクされた内部記録が必要です。受入の証拠とともにログを保管してください。

必要がないなら、売り手の秘密のデプロイ仕組みまで求める必要はありません。結果を再現するのに十分な手順と設定を求めます。同じ必要な段階を実行し、リリース管理を弱めないなら、移植可能なパイプラインは別のCI製品を対象にしても構いません。

モバイルアプリケーションには、署名用資産、パッケージ識別子、ストアアカウント、プッシュ通知の認証情報が加わります。ソースビルドがエミュレーターで動くため、見落としやすいものです。配布アカウントを顧客が所有していることを確認し、証明書のローテーションを文書化します。サーバーとWebアプリケーションでは、ドメイン検証、TLS証明書の発行、DNS変更、キャッシュ無効化もリリース演習に含めます。

パイプラインテストは、提供されたコミットを再ビルドするだけでは終わりません。無害で目に見える変更を加え、ロールバック可能なデータベースマイグレーションを追加し、ビルドしてステージングへデプロイし、検証してロールバックを実行します。これにより、一度だけコミットされたものの再生成できない生成済み成果物を見つけられます。

ビルドに使うOSパッケージも、言語ツールチェーンとともに固定します。ネイティブモジュールは、ビルダーのイメージにたまたまあるライブラリを前提にコンパイルされる場合があります。新しいランナーではアプリケーションテストの前に失敗するか、さらに悪いことに動作の異なる成果物ができるおそれがあります。コンテナ定義か、それと同等の機械可読なビルド記述に、パッケージ名とバージョンを記録します。

CIログからシークレットを除外しつつ、パイプラインが顧客管理のストアからシークレットを取得できることを証明します。テストでは、短命のステージング用認証情報を作成し、文書化された方法で注入し、ソースを編集せずにローテーションできることを確認します。サポート担当者がベンダーのダッシュボードへシークレットを貼り付ける必要があるなら、セットアップメモに隠さず、その依存関係を記録してください。

クリーンルームデプロイでホスティングの前提が明らかになる

クリーンルームデプロイは、ビルダーに詳しくないチームが、エクスポートしたもの、宣言されたサービス、文書化された手順だけを使って顧客所有の環境にシステムを起動できるとき、可搬性を証明します。契約受入前に、時間制限と課題ログを設けて実行します。

意図した運用モデルに合う環境を選びます。マネージドプラットフォームから生の仮想マシンへ移すと、関係のない作業が増え、可搬なプロジェクトでも壊れているように見えることがあります。コンテナ、PostgreSQL、オブジェクトストレージ、定期ジョブ、シークレット、ロードバランシングといった必要な要素は合わせますが、文書化されていないベンダー独自の仕組みまで再現しないでください。

書き込み可能なローカルディスク、固定ポート、スティッキーセッション、信頼するプロキシヘッダー、リージョン名、注入されるホスト名、プラットフォーム固有の環境変数を前提にしていないか、アプリケーションを確認します。Twelve-Factor Appでは、設定を環境に保存し、バックエンドサービスを接続されたリソースとして扱うことを推奨しています。この考え方は今も有用ですが、環境変数だけでは所有者、形式、作成方法は分かりません。各変数に運用記録を対応付けてください。

ヘルスチェックは直接テストする価値があります。マイグレーション完了前や必須の依存関係に接続する前に成功を返すプロセスは、オーケストレーターの背後で再起動ループに入ることがあります。ホスティングシステムが対応しているなら、livenessとreadinessを分けます。データベース、オブジェクトストア、キューを1つずつ停止し、ステータスコード、ログ、再試行動作、サービス復帰後の回復を観察します。

アプリケーションが複数インスタンスをどう扱うかを確認します。メモリ内セッション、ローカルのアップロードディレクトリ、プロセスローカルのジョブロックは、1つのマネージドインスタンスでは動いても、スケール後に失敗します。2つのインスタンスを起動し、同じユーザーのリクエストを両方に送り、並行したジョブワーカーを実行します。セッションが維持されること、ファイルを利用できること、定期タスクが冪等に設計されている場合を除いて二重実行されないことを確認します。

起動と同じくらい、停止時も注意深く観察します。リクエストとバックグラウンドジョブが動いている間に終了シグナルを送ります。プロセスは新規の仕事の受け付けを止め、取得済みジョブを完了するか安全に戻し、接続を閉じ、ホストの猶予時間内に終了すべきです。マネージドビルダーは、長いタイムアウトや、移行先ホストにはない再試行で、突然の終了を隠していたかもしれません。

ログとメトリクスにもホスティングの前提があります。アプリケーションが構造化されたイベントを文書化済みの宛先へ書き、必要に応じてシークレットや個人データを除外し、失敗した操作フローを診断するのに十分な情報を出すことを確認します。標準出力や別の顧客管理の出力先が必要な証拠を残せるなら、プロプライエタリなダッシュボードは必須ではありません。

リージョンとデータ所在地に関する主張には、設定の証拠が必要です。アプリケーション、データベース、バックアップ、ログ、オブジェクトストレージがどこで動くかに加え、どの外部サービスにデータが送られるかを記録します。Webプロセスでリージョンを選んでも、認証や分析が別の場所へデータを送るなら、その国にデータがとどまるわけではありません。契約には、それらの場所の変更を誰が承認するかを記載すべきです。

Koder.ai はソースエクスポート、デプロイとホスティング、カスタムドメイン、スナップショット、ロールバックに対応しています。エクスポートした Koder.ai プロジェクトを独立運用できるか評価するなら、同じクリーンルーム基準を使ってください。エクスポートした React、PostgreSQL を使う Go、Flutter の各コンポーネントを、自社で所有する予定の環境でテストし、使い続けるサービスはすべて文書化します。

合格・不合格の条件を契約に入れる

契約では可搬性を観察された動作として定義し、受入環境を一覧にし、是正の責任を割り当て、最終支払いやロックインの前に問題を修正する十分な時間を確保します。曖昧な所有権の文言では、誰もデプロイできないアプリケーションを救えません。

「ソースコード」という見出しの段落に頼らず、受入マトリクスを添付します。各行には機能、テスト手順、期待結果、証拠、担当者、重大度を記載します。コールドビルド、実行時ネットワーク呼び出し、アイデンティティ移管、データベース復元、ファイルストレージ、バックグラウンド処理、CI、クリーンなデプロイ、監視、バックアップ復元、小さな変更、ロールバックを対象にします。

第三者が観察できる合格基準を使います。「重大なプロプライエタリ依存関係がない」では議論を招きます。「ビルダー所有の認証情報を無効化し、ビルダーのドメインを遮断した状態で、ステージングアプリケーションが操作フローAからFを完了する」ならテストできます。チームが承認済みのマネージドサービスを失敗と誤認しないよう、許可する依存関係を名前とアカウント所有者で定義します。

固定したリビジョンで、ソースと運用資料を納品するよう求めます。ロックファイル、マイグレーション、ビルド定義、利用可能な場合のインフラ設定、環境変数カタログ、依存関係台帳、データエクスポート、アイデンティティ移行計画、運用手順書、ライセンス通知、顧客に帰属する署名または配布用資産です。除外項目も明確に記録します。何も書かれていないことを受入と見なしてはいけません。

重大度は事業への影響で決めます。任意の分析イベントが1つ欠けることと、ログイン停止は同じではありません。ビルドや主要な操作フローを妨げるブロッカー、重要な機能や復旧経路を失わせる重大な欠陥、文書化された回避策がある軽微な欠陥を区別する仕組みが役立ちます。普遍的な日程を勝手に決めず、それらのレベルに受入日と是正期限を結び付けます。

テストデータとテスト担当者も定義します。売り手は、空のデータベースと通常の認可を回避できる管理者アカウントで可搬性を示すことがあります。代表的なユーザー、ロール、ファイル、バックグラウンドジョブを用意し、顧客側スタッフが文書化された手順を実行するよう求めます。シークレットはダミーのままにしつつ、関係と境界ケースは現実的に保ちます。

費用も証拠パケットに含めます。エクスポートしたリリースを動かすのに必要な個別課金サービスと、売り手が示した最低プラン、データ転送料、非公開レジストリのサブスクリプションを記録します。テストで将来の請求額をすべて予測する必要はありません。独立しているはずのエクスポートに、契約後になって避けられないベンダー契約が必要だと分かる事態を防ぐことが重要です。

すぐには移管できないサービスについては、協力義務を含めます。売り手が鍵をローテーションし、アイデンティティエクスポートを承認し、ドメインを移し、最終データスナップショットを提供する必要があるかもしれません。行う作業と責任者を明記します。本番が停止しているとき、「合理的な支援」は強制しにくい表現です。

是正後と最終エクスポート後にテストを繰り返す権利を残します。生成されたプロジェクトは急速に変わり、先月のリビジョンで証明された修正は、昨日追加された新しい依存関係について何も示しません。受入記録には、テストしたコミットと成果物ハッシュを固定して記載します。

エスクロー条項でこの作業を代替させないでください。エスクローなら、条件となる事態が起きた後にファイルを渡せるかもしれません。しかし、最新のビルド手順、認証情報の所有権、検証済みの復旧経路がなければ、役に立つには遅すぎる可能性があります。両者がまだ協力できるうちに、運用上の独立性を確立しなければなりません。

元のビルダーから特権的な支援を受けずに、別のチームが受入済みリリースをビルド、実行、変更、デプロイ、復旧できるなら契約しましょう。それに満たないものは、未解決の移行プロジェクトが付いたソースの保有にすぎません。契約金額にも、その作業を反映させるべきです。