Lovable Cloud から Supabase への移行は、単純なデータベースのダンプとリストア以上のものです。特に認証、AI 機能、メールサービスに関して、移行後に多くの問題が発生します。包括的なチェックリストが不可欠であり、それが GitHub リポジトリを分析する無料の移行チェッカーの作成につながりました。Lovable Cloud プロジェクトには、スキーマ変更のための 'supabase/migrations'、エッジ関数用の 'supabase/functions'、プロジェクト設定用の 'supabase/config.toml' のような不可欠なバックエンドコンポーネントが含まれています。重要なのは、生成された型ファイル 'src/integrations/supabase/types.ts' が公開テーブルの正確なリストを提供し、Cloud UI の変更がマイグレーションに記録されていなかった場合のスキーマのずれを明らかにすることです。移行プロセスでは、拡張機能、次にスキーマ、その次に機能、トリガー、そして最後にデータを優先する必要があります。新しいユーザープロファイルの問題を防ぐために、'auth.users' のトリガーには特別な注意が必要です。ユーザーが既存の認証情報でログインできるように、パスワードハッシュを含む 'auth.users' および 'auth.identities' を含む 'auth' スキーマをコピーすることが不可欠です。ストレージの移行は特に面倒で、ストレージ API に対してスクリプトを作成するか、'rclone' を使用して S3 エンドポイント間でファイルを転送する必要があります。バケットは、同一の名前と設定で再作成する必要があります。移行後の一般的な破損箇所には、Google サインインがあり、古いプロジェクトでは Lovable の OAuth ブローカーがデフォルトで使用されます。これには、Google Cloud Console で独自の OAuth クライアントを設定し、フロントエンドの呼び出しをプレーンな 'supabase.auth.signInWithOAuth' を使用するように更新する必要があります。Lovable の AI ゲートウェイの呼び出しは、エッジ関数に埋め込まれており、Lovable Cloud 外では失敗するため、新しい AI プロバイダーのキーと URL が必要になります。サインアップメールも届かなくなります。これは、新しい Supabase プロジェクトのメールサービスが制限されているためです。Resend や Postmark のようなカスタム SMTP が必要になります。さらに、しばしば見落とされる cron ジョブには、古いプロジェクトの URL がハードコードされており、無効になった Lovable Cloud インスタンスへの呼び出しが継続される可能性があります。移行チェッカーは、公開 GitHub リポジトリのファイルに対するパターンマッチングによってこれらの問題に対処します。高速で依存関係がない一方で、SQL 解析には正規表現に依存しており、マイグレーションに反映されていないダッシュボードでの変更を検出することはできません。これは、決定的な監査ではなく、チェックリストとして機能します。プロフェッショナルな支援を希望する場合は、固定価格の移行サービスが利用可能です。