既存の本番プロダクトを新基盤（VPS・PaaS・コンテナオーケストレーション基盤など）へ移行する計画があり、同時期に新プロダクトの置き場も必要な場合、載せる順序で移行リスクを大きく下げられる。

判断

基盤構築だけを先行実施し、ユーザー・課金・外部連携（OAuth・webhook 等）を持たない新プロダクトを最初のテナントとして載せる。デプロイフロー・バックアップ・証明書・監視といった基盤運用を新プロダクトで枯らしてから、本番プロダクトの載せ替えに進む。

理由

• 移行計画をそのまま実行すると、本番ユーザー・課金・外部連携を抱えたプロダクトが新基盤の初検証台になり、基盤側の初期不良と移行作業のリスクが重なる。
• グリーンフィールドの新プロダクトは DNS 切替・データ移行・新旧並走が不要で、新規デプロイだけで済むため失敗コストがほぼゼロ。基盤検証の実地演習として最適。
• 新プロダクト側も置き場が即決まり、基盤整備が開発のブロッカーにならない（基盤が立つまではローカル環境で開発を進められる）。

適用条件

• 新基盤が複数プロダクトを載せる前提の共有基盤であること。
• 新プロダクトの信頼性要求が本番プロダクトより低いこと（ユーザーゼロ・収益ゼロの段階）。

落とし穴

初代テナントで枯らせるのは基盤運用（構築・デプロイ・バックアップ・証明書）まで。本番プロダクトの移行で初めて踏む領域（データ移行、秘密値の転記、webhook・OAuth の到達確認）は残るため、移行リハーサルは本番側の移行計画で別途担保する。