Sitecore XM Cloud を Next.js ヘッドレスに移行

エンタープライズチームが Sitecore XM Cloud を離れている理由

Sitecore の JSS サポート終了は 2026 年 6 月です。これは遠い期限ではなく、今からそれまでの間、チームが計画するすべてのスプリントに対する現実的な制約です。技術的には健全な Content SDK への強制的な移行は、エンタープライズチームがコンポーザブルアーキテクチャへ移行しつつある正にそのときに、Sitecore のロードマップへのロックインをさらに深めてしまいます。

マルチマーケット、マルチブランドのデジタルプロパティを運営するエンタープライズ組織の XM Cloud からの撤退を主導してきました。パターンは一貫しています。チームは XM Cloud の独断的なレンダリングパイプラインに頭打ちになり、ライセンス費用が年 50,000 ドルを超え、Sitecore のツール群と現代的な Next.js のギャップが四半期ごとに広がり続けます。

これは Sitecore が劣悪なソフトウェアだという話ではありません。チームが、企業ファイアウォール内の ISR 無効化を処理するためだけに逆プロキシハックが必要でないアーキテクチャを享受する資格があるという話です。

XM Cloud からの脱出を促進する痛点

JSS サポート終了が強制的な移行債務を生み出す

JSS のサポートは 2026 年 6 月に終了します。JSS 上に残るすべてのエンタープライズチームは 2 つの選択肢に直面します。Content SDK に移行する（Sitecore エコシステム内に留まる）か、コンポーザブルスタックに撤退するかです。Content SDK への移行は、パッケージの更新、新しい環境変数、異なるルーティングパターン、Pages Router から App Router への移行を意味します。これは週末のプロジェクトではなく、本番トラフィックを実行しているチームにとっては複数四半期にわたるイニシアチブです。

ここに皮肉があります。既に 6 ヶ月以上をフロントエンドのリファクタリングに投資するのであれば、なぜベンダーロックインをより深めるほうにリファクタリングするのではなく、自由に向かってリファクタリングしないのでしょうか。

ライセンスと総所有コスト

XM Cloud の基本ライセンスはテナントごとの費用や API コールオーバーチャージ、本番環境で Next.js デプロイメントを実行し続けるために必要な Sitecore パートナー時間を差し引いても、年間約 50,000 ドルから始まります。その上に Vercel ホスティングを追加します。Sitecore は本質的に本番 Next.js デプロイメントに Vercel を要求しています。CMS とレンダリングレイヤーの両方に対してプレミアム価格を支払っていることになります。

コンポーザブルな代替案（たとえば Sanity または Contentful と Vercel 上の Next.js のペアリング）は通常、総所有コストの 40～60% 少ないコストで実行でき、レンダリングパイプラインの完全な制御をチームに与えます。

開発者体験とタレントパイプライン

Sitecore JSS 開発者プールは縮小しています。Content SDK はより新しく、ドキュメント化が少なく、ほとんどの React 開発者が持っていない、そして本当に学びたくない Sitecore 固有の知識を必要とします。XM Cloud に留まるたびに四半期が経つと、採用はますます難しくなり、オンボーディングに時間がかかります。

現代的な Next.js とヘッドレス CMS ですか？それはすべてのシニアフロントエンド開発者が既に知っているスタックです。タレントパイプラインは細い流れから消防ホースになります。

エッジレンダリングの制限とネームスペースの複雑性

XM Cloud のレンダリングアーキテクチャは、エッジレンダリング用に特定のパターンを強制します。マルチサイトセットアップ全体でのネームスペーシングは設定の迷路になります。環境変数が増殖し、ビルド設定が分裂し、デバッグにはフロントエンドチームが触るべきではない Sitecore 固有のツールが必要です。

ネイティブ Next.js App Router とミドルウェアベースのルーティングで、マルチテナントネームスペーシングを綺麗に処理します。エッジレンダリングは単に機能します。HAProxy ハックなし、ISR 無効化コールバックのために企業ファイアウォールを貫通する逆プロキシ設定なし。

Next.js ヘッドレスアーキテクチャで得られるもの

真のコンポーザブル DXP

CMS を選びます — Sanity、Contentful、Storyblok、またはいくつかのその投資を保持したい場合は Sitecore Content Hub さえも。コマースエンジンを選びます。パーソナライゼーションレイヤーを選びます。各部分はベストオブブリード、独立してスケーラブル、フロントエンドからスクラッチで再構築することなく置き換え可能です。

実際にビジネスメトリクスを動かすパフォーマンス

移行後のプロパティで Lighthouse モバイルスコア 95～100 を継続的に提供しています。TTFB は XM Cloud サーバーレンダリングページの典型的な 1.2～2.5 秒の範囲から ISR とエッジキャッシングで 300 ミリ秒未満に低下します。エンタープライズサイトで 100 ミリ秒のページロード改善が測定可能なコンバージョンリフトと相関する場所では、それは虚栄心のメトリクスではなく — それは収益です。

ISR + エッジキャッシング、正しく実装

Next.js ISR と Vercel のデータキャッシュは冗長な Sitecore API コールを排除します。移行中に原点リクエストで 70% の削減が測定されています。ページは実行時に増分で再生成されるため、SSG レベルのパフォーマンスでほぼリアルタイムのコンテンツ新鮮度を得られます。ビルド時間のボトルネックなし、月曜日の午前 9 時にマーケティングからの古いコンテンツの苦情なし。

モダンな Content SDK 互換性（必要な場合）

コンテンツバックエンドとして Sitecore を保持しつつ XM Cloud レンダリングレイヤーを削除したいチームの場合、Content SDK API を直接消費する Next.js フロントエンドを構築します。既に作成したコンテンツモデリング投資を保持します。戦ってきたレンダリング制約を削除します。

当社の移行プロセス

フェーズ 1：アーキテクチャ監査とコンテンツマッピング（1～3 週目）

XM Cloud インスタンス内のすべてのコンポーネント、テンプレート、レンダリングバリアント、コンテンツタイプをインベントリします。Sitecore のコンテンツツリーをヘッドレス CMS コンテンツモデルにマッピングします。きれいに変換されるもの、リストラクチャが必要なもの、単に削除できるものを把握します。適切な場所で Sitecore XM Migration Tool をコンテンツシリアライゼーションに使用します。

フェーズ 2：Next.js でのフロントエンドリビルド（4～10 週目）

TypeScript を使用して Next.js App Router でコンポーネントライブラリをリビルドします。各コンポーネントにはコンテンツ変動性に基づいて ISR または SSG レンダリング戦略が割り当てられます。マルチサイトルーティング、ロケール処理、パーソナライゼーショントリガー用にエッジミドルウェアを実装します。デザインシステムトークンは引き継ぎます — ブランドは変わりません、アーキテクチャが変わります。

フェーズ 3：コンテンツ移行と CMS セットアップ（6～10 週目）

フロントエンド開発と並行して、自動スクリプトと Sitecore シリアライゼーションフレームワークを使用してコンテンツを移行します。メディアアセットは CDN ネイティブソリューション — Cloudinary、Vercel Blob、または CMS のアセットパイプラインに移動します。本番環境への移行前にコンテンツエディターに新しい CMS のトレーニングを実施します。後ではなく。前に。

フェーズ 4：SEO 保持と起動（10～14 週目）

これは移行が成功するか失敗するかが決まるポイントです。

SEO 保持戦略

SEO 保持をファーストクラスのエンジニアリング関心事として扱い、事後的ではありません。

• 完全な URL 監査と 301 リダイレクトマッピング — インデックス済みのすべての URL は起動前にリダイレクトルールを取得
• メタデータ移行 — タイトルタグ、メタディスクリプション、Open Graph データ、構造化データはすべてプログラムで転送
• XML サイトマップ生成 — ヘッドレス CMS コンテンツから構築された動的サイトマップ、起動前に Search Console に送信
• Core Web Vitals 改善 — 移行は通常、CWV スコアを大幅に改善し、Google が報酬を与えます
• 正規タグ保持 — 移行中または移行後の重複コンテンツシグナルなし
• クロールバジェット監視 — 起動後 90 日間 Search Console で監視し、インデックス作成の問題をいち早く発見

移行では有機トラフィックを失ったことはありません。それは運ではなく — それはプロセスです。

タイムラインと投資

エンタープライズ XM Cloud 移行は、通常、中程度の複雑なプロパティ（50～200 テンプレート、5,000～50,000 コンテンツアイテム）の場合、12～16 週間実行されます。より大規模なマルチマーケットデプロイメント（パーソナライゼーションとコマースの統合）は 20～24 週間に延長されます。

投資はスコープ、マーケット数、統合の複雑さに応じて $120,000～$350,000 です。年間 XM Cloud ライセンス費用に加えて、どちらにしても実行する強制的な Content SDK 移行のコストに対抗するまで、それは多くに聞こえます。

ほとんどのチームは削減されたライセンス、より高速な開発速度、より優れたパフォーマンスからのコンバージョン改善を通じて 12 ヶ月以内に ROI を達成します。

エンタープライズ Sitecore 撤退に社会動物を選ぶ理由

次の Sitecore 製品を売却しようとしている Sitecore パートナーではありません。エンタープライズ Sitecore を十分に深く理解し、きれいに撤退させることができるヘッドレス開発エージェンシーです。Aryan Shah が率いるプラットフォーム移行チームは、数十のマーケット全体で月単位で数百万のセッションを実行している組織の XM Cloud 撤退をこなしてきました。

Content SDK の内部を知っています。XM Cloud のレンダリングパイプラインがスケール時に壊れる場所を知っています。そしてチームがより高速に配信し、サイトがより高速に読み込まれ、総所有コストが 3 分の 1 以上削減されるように Next.js で再構築する方法を知っています。