Azure Logic Apps Consumption Integration Accounts は、古いランタイムで実行されている約 60,000 の Azure Functions アプリによって支えられていました。チームは、顧客によるアクションを必要とせずに、これらのすべてのアプリケーションを新しい Functions v4 ランタイムに正常に移行しました。これは、互換性を確保し、混乱を最小限に抑えるように設計された、綿密な多段階アプローチを通じて達成されました。中核となる戦略はシャドーイングを含み、実際の運用トラフィックが古いランタイムと新しいランタイムの両方に同時にルーティングされました。これにより、実証されていないパスが顧客に影響を与えることなく、すべての結果を直接比較することができました。重要な側面は、堅牢なパリティバーを確立することであり、適格なトラフィックの 100% が分析され、実際のバグと本来決定論的でないワークロードを区別できるようにしました。検出された実際の相違点は、トラフィックがシフトされる前に綿密に修正されました。ロールアウトは段階的かつ元に戻すことが可能であり、トラフィックはトラフィックハッシュに基づいてリージョンごとに徐々に移動されました。重要な機能は、単純な構成変更を通じてマイグレーション全体をロールバックできることであり、数分以内に有効になりました。古いアプリケーションの廃止は、細心の注意を払って処理されました。古いアプリは最初に停止され、その後、永久に削除される前にかなりの観察期間が設けられました。この段階的なアプローチにより、予期しない問題が発生した場合でも、顧客に影響を与えることなく対処できることが保証されました。この複雑な移行は、Microsoft が基盤となるコンピューティングインフラストラクチャを所有および運用していたため可能になりました。契約やスキーマなどの永続的な顧客データはそのまま維持され、実行されたアクションは純粋な変換でした。このコントロールプレーンにより、両方のランタイムの並列実行と比較が可能になりました。主な課題は新しいランタイム自体ではなく、既存の顧客ワークロードとの互換性を証明することでした。レガシーランタイムはサポート終了が近づいており、リスクが増大していました。60,000 のアプリケーションにわたる運用規模とホストモデルの変更により、分離されたワーカーモデルを備えた Azure Functions v4 への移行は、大幅なアーキテクチャの変更を表していました。インプレースアップグレードや単純なデプロイスロットのような標準的な軽量移行オプションは、ホストモデルの変更と 60,000 アプリケーションにわたる運用の規模により、不十分と見なされました。移行により、顧客に見える混乱は発生しませんでしたが、ロールバックが開始される前に、少数の顧客が大量の負荷の下で短いエッジケースに遭遇しました。チームは、顧客にシームレスなエクスペリエンスを提供するために、複雑さを吸収しました。