LASSIC Media らしくメディア
BizTalk Serverサポート終了、移行と外注検討
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- BizTalk Server 2020は、Microsoft公式ライフサイクル情報において最終メジャーバージョンと位置づけられており、メインストリームサポート終了は2028年4月11日、延長サポート終了は2030年4月9日です。
- Microsoftは後継としてAzure Logic Apps Standardを含むAzure Integration Servicesへの移行を案内しており、公式ガイドは「ビッグバン」ではなく反復・ウェーブ型の移行を推奨しています。
- 移行は資産の棚卸しから設計・開発・テスト・カットオーバーまで複数分野の専門知識を要するため、内製と外注のどちらで進めるかを早期に判断する必要があるでしょう。
目次
- BizTalk Serverとは？企業間・システム間連携を支えてきたMicrosoftの統合基盤
- BizTalk Server 2020は最終メジャーバージョン、サポート終了はいつか
- 旧バージョンのサポート終了状況と確認すべきポイント
- サポート終了後も使い続けるリスク
- 移行先となるAzure Integration Servicesの全体像
- 移行アプローチの選び方：ビッグバンと反復移行（ウェーブ型）
- 移行プロジェクトの進め方：Discovery（Sprint 0）からカットオーバーまで
- 内製移行と外注委託のコスト構造比較
- 内製に必要なスキルと外注委託した場合の違い
- まとめ：BizTalk Server移行を進める3つの判断軸
- よくある質問
BizTalk Serverとは？企業間・システム間連携を支えてきたMicrosoftの統合基盤
BizTalk Serverは、企業内の基幹システム同士や取引先とのB2B/EDI連携を仲介する、MicrosoftのEAI（Enterprise Application Integration）基盤です。Microsoft公式の移行ガイドは、BizTalk Serverが25年以上にわたり金融・医療・製造・行政など幅広い業界のミッションクリティカルな統合ワークロードを支えてきたと説明しています*4。
アーキテクチャの中核は、メッセージ・プロパティ・サブスクリプション・オーケストレーション状態などを保持するMessageBoxデータベースを用いた、パブリッシュ・サブスクライブ型のメッセージングエンジンです*4。受信したメッセージをパイプラインで正規化してMessageBoxへ発行し、登録済みのサブスクリプション（フィルタ）に基づいてオーケストレーションや送信ポートへルーティングする仕組みで、長年にわたり企業間連携の要として使われてきました*4。こうした資産を多く抱える企業ほど、次の統合基盤への移行は計画的に進める必要があるでしょう。
BizTalk Server 2020は最終メジャーバージョン、サポート終了はいつか
Microsoft公式ライフサイクル情報によると、BizTalk Server 2020の提供開始日は2020年2月1日（米国太平洋時間）です*1。メインストリームサポートの終了日は当初2024年1月9日でしたが、Microsoftはこれを2028年4月11日まで延長すると発表しました*2。現在の公式ライフサイクルページでも、メインストリームサポート終了日は2028年4月11日、延長サポート終了日は2030年4月9日（いずれも米国太平洋時間）と明記されています*1。
さらに重要な点として、Microsoftは移行ガイドの中で「BizTalk Server 2020はBizTalk Serverの最終バージョンである」と明記しています*4。つまり、BizTalk Server 2020より新しいメジャーバージョンが今後リリースされる予定はなく、Azure Logic Apps Standardを中心とするAzure Integration Servicesが後継の統合プラットフォームと位置づけられているということです*4。BizTalk Server 2020を使い続ける場合でも、2030年4月9日の延長サポート終了までに、次の統合基盤への移行計画を立てておく方がよいでしょう。
旧バージョンのサポート終了状況と確認すべきポイント
BizTalk Server 2020より前のメジャーバージョンでは、サポート終了がすでに到来しているものもあります。例えばBizTalk Server 2016は、公式ライフサイクルページによると提供開始日が2016年12月1日、メインストリームサポート終了日が2022年1月11日、延長サポート終了日が2027年1月11日とされています*3。つまりメインストリームサポートはすでに終了しており、延長サポート期間に入っている状態です*3。
2013 R2以前のバージョンについては、本稿執筆時点で公式ライフサイクル情報の個別確認を行っていません。自社が利用しているバージョンのサポート期限は、Microsoft公式のライフサイクル検索ページで個別に確認することを推奨します。バージョンによってサポート期限は異なるため、移行の優先順位を検討する際は、まず自社環境のバージョンとサポート期限を突き合わせるところから着手するとよいでしょう。
サポート終了後も使い続けるリスク
Microsoftはメインストリームサポート延長の発表の中で、メインストリームサポート期間内であれば「セキュリティ更新プログラムの提供、非セキュリティ更新プログラムのリクエスト、インシデントサポートの受領」ができると説明しています*2。裏を返せば、サポートが終了した領域ではこうした対応を受けられなくなるということです。企業間連携やEDIのように取引先とのデータ交換を担う基盤が保守対象外になると、障害発生時に修正プログラムを受けられず、業務停止が長期化する懸念が高まります。
Microsoftは同発表の中で、クラウドソリューションへの移行検討を顧客に促しつつも、既存顧客への現行サポートは継続すると述べています*2。この姿勢からは、Microsoft自身がBizTalk Serverを長期にわたる主力製品として位置づけていないことがうかがえます。サポート期限を待たずに、計画的な移行検討を始めることが望ましいでしょう。
移行先となるAzure Integration Servicesの全体像
Microsoftの公式移行ガイドでは、Azure Logic Apps Standardは「Azure Integration Servicesの一部」であり、BizTalk Serverが提供してきた価値を引き継ぎながら、新しい技術革新・スケール・インテリジェンスを取り入れた最新の統合プラットフォームだと説明されています*4。Azure Logic Apps Standardには、BizTalk Serverのビジネスルールエンジン（BRE）と同じランタイムを使うAzure Logic Apps Rules Engineが含まれるほか、HL7・MLLP・SWIFTなど多くの技術に直接対応するコネクタが用意されており、BizTalk Serverでの投資を活かしながら移行できる設計になっています*4。
パブリッシュ・サブスクライブ型のメッセージングは、Azure Service BusのトピックとサブスクリプションやRabbitMQを使って実現し、SOAPレガシー資産の連携にはAzure API Managementを組み合わせる構成が公式ガイドで紹介されています*4。従量課金型の価格モデル（Consumption-based pricing）により、ライセンスとインフラへの先行投資を抑えられる点も、Microsoftが移行のメリットとして挙げているポイントの一つです*4。
移行アプローチの選び方：ビッグバンと反復移行（ウェーブ型）
Microsoft公式の移行アプローチガイドは、移行戦略として「ビッグバン（直接切り替え）」と「反復型・ウェーブ型」の2つを挙げています*5。ビッグバンは多くの計画を要するアプローチであり、Azure Logic Appsに不慣れな組織や、大規模・高複雑度のシステムを抱える組織には推奨されないとされています。小規模で複雑度の低いBizTalkワークロード、自社環境に精通したSME（サブジェクトマターエキスパート）、BizTalk機能とAzure Logic Appsの直接的なマッピングが揃っている場合に限り検討する選択肢と位置づけられています*5。
一方、公式ガイドが推奨しているのは反復型・ウェーブ型のアプローチです*5。段階的に価値を積み上げられるうえ、プロジェクトチームが早い段階で技術スタックを学習し、振り返りを重ねながら管理・スケーラビリティ・運用・監視の知見を次のスプリントへ反映できる点がメリットとされています*5。サーバーインフラを廃止する前に、BizTalk Serverのソリューションをリファクタリングしておくことも強く推奨されている進め方です*5。
移行プロジェクトの進め方：Discovery（Sprint 0）からカットオーバーまで
公式ガイドは、反復型・ウェーブ型アプローチにScrumプロセスを組み合わせて進めることを推奨しています*5。最初の「Sprint 0」では、BizTalk Server環境のDiscovery（棚卸し）とウェーブ計画を実施します。具体的には、利用中のアダプター、BizTalk機能（Business Activity Monitoring、Business Rules Engine、EDI等）、カスタムコード、メッセージスループット、依存関係などの情報を収集し、インターフェースやアプリケーションごとに複雑度を割り当てる作業が含まれます*5。
Sprint 0では、アーキテクチャ設計とMVP（Minimum Viable Product）定義、初期バックログの作成も並行して行います。公式ガイドは、BizTalk移行をAzure Well-Architected Frameworkにおける「ミッションクリティカルワークロード」として扱い、可用性と回復性を重視した設計方法論に沿って進めることを推奨しています*5。Sprint 0の後は、複数のスプリントからなる「ウェーブ」単位で移行・テスト・本番リリースを繰り返す流れになります*5。
本番切り替えの際は、コミュニケーション計画とカットオーバー計画（前提条件の確認、リハーサル、体制、スケジュール、BizTalk側インターフェースの無効化とLogic Apps側の有効化、検証テスト、ロールバック計画等）を整備することが推奨されています*5。また公式ガイドは、各移行フェーズでGitHub CopilotベースのAzure Logic Apps Migration Agent拡張機能（Visual Studio Code向け）を使うと、Discovery・分析・変換を含む5段階の移行ワークフローをAIが支援すると紹介しています*5。
内製移行と外注委託のコスト構造比較
ここまで見たとおり、BizTalk Server移行はDiscoveryからアーキテクチャ設計、開発、テスト、カットオーバーまで多岐にわたる工程を必要とします。内製で進める場合と外部パートナーへ委託する場合とでは、必要なスキルセットとリスクの負い方が異なるでしょう。以下の表に主な違いを整理しました。
| 比較項目 | 内製移行 | 外注委託 |
|---|---|---|
| 必要な専門知識 | BizTalk ServerとAzure Logic Apps Standard双方の知識、Well-Architected Frameworkに基づく設計手法、Scrumでのプロジェクト運営が必要になります*5 | 複数のBizTalk移行案件を手掛けてきた専門パートナーが、設計から開発・テストまで一貫して対応します |
| Discovery（資産の棚卸し） | アダプター・カスタムコード・依存関係などを自社で洗い出し、複雑度を評価する体制を整える必要があります*5 | 移行支援ツールや過去案件の知見を活用し、棚卸しの精度とスピードを高めやすくなります |
| 移行アプローチの設計 | ビッグバンか反復型か、自社の複雑度やSMEの有無を踏まえて判断する必要があります*5 | 複雑度評価やウェーブ計画の立案を、豊富な移行実績に基づいて提案してもらえます |
| カットオーバー・リスク管理 | ロールバック計画や検証テストの設計・実行を自社で担う必要があります*5 | 本番切り替えの体制構築からリハーサルまで含めて任せられます |
内製に必要なスキルと外注委託した場合の違い
内製でBizTalk Server移行を進める場合、求められる知識は多岐にわたります。BizTalk Server側のオーケストレーション・パイプライン・マップ・ビジネスルールの仕様理解に加えて、Azure Logic Apps Standardのワークフロー設計、Visual Studio Codeでの開発、Bicep・Terraform等によるInfrastructure as Codeでのデプロイ、Azure Well-Architected Frameworkに基づくミッションクリティカルワークロードの設計手法まで、複数分野の専門性が求められます*5。
判断を先延ばしにしたまま自己流で移行を進めると、Discoveryが不十分なまま開発に着手し、後工程で想定外の依存関係やカスタムコードが見つかって手戻りが発生するといった事態につながりかねません。特にビッグバン型は「不慣れな組織や大規模・高複雑度のシステムには推奨されない」とMicrosoft自身が明言しているだけに*5、自社にBizTalk ServerとAzure Logic Apps Standard双方の知見を持つ人材が十分に揃っているかどうかが、内製か外注かを判断する分かれ目になるでしょう。
専門パートナーに依頼した場合は、Discoveryからアーキテクチャ設計、ウェーブごとの開発・テスト、カットオーバー計画の策定まで一連の工程を任せられます。複数の統合基盤移行を扱ってきた知見を活用すれば、自社だけでは判断に時間がかかる場面でも、進め方の型化によって稼働までの期間を圧縮しやすくなるでしょう。内製・外注のどちらを選ぶ場合でも、まずは自社のBizTalk資産の棚卸しから着手することが出発点と言えます。
まとめ：BizTalk Server移行を進める3つの判断軸
本稿ではBizTalk Serverのサポート終了状況と、Azure Integration Servicesへの移行の考え方を、Microsoft公式のライフサイクル情報と移行ガイドに基づいて整理しました。要点は次の3つに集約されるでしょう。第一に、BizTalk Server 2020は最終メジャーバージョンであり、メインストリームサポート終了は2028年4月11日、延長サポート終了は2030年4月9日です*1*4。第二に、Microsoftは反復・ウェーブ型の移行アプローチを推奨しており、ビッグバンによる一括移行は小規模かつ低複雑度のワークロードに限定した選択肢とされています*5。第三に、Discoveryからカットオーバーまでの工程にはBizTalk ServerとAzure Logic Apps Standard双方の専門知識が求められるため、内製での対応が難しい場合は外部委託によってリスクを抑えながら移行を進めやすくなります*5。
よくある質問
BizTalk Server 2020のサポートはいつまでですか。
Microsoft公式のライフサイクル情報によると、メインストリームサポート終了日は2028年4月11日、延長サポート終了日は2030年4月9日です（いずれも米国太平洋時間）*1。メインストリームサポートは当初2024年1月9日までとされていましたが、2028年4月11日まで延長されています*2。
BizTalk Server 2020は本当に最後のバージョンですか。
はい。Microsoftの公式移行ガイドは「BizTalk Server 2020はBizTalk Serverの最終バージョンである」と明記しており、後継としてAzure Logic Apps Standardを含むAzure Integration Servicesへの移行を案内しています*4。
BizTalk Server 2016などの旧バージョンはどうなっていますか。
BizTalk Server 2016は、メインストリームサポートが2022年1月11日にすでに終了しており、延長サポート終了日は2027年1月11日です*3。それ以前のバージョンについては、Microsoft公式のライフサイクル検索ページで個別に確認することをおすすめします。
移行はビッグバンで一気に進めるべきですか。
Microsoft公式ガイドは、ビッグバン（一括切り替え）を小規模で複雑度の低いBizTalkワークロードに限った選択肢とし、多くの組織には反復型・ウェーブ型のアプローチを推奨しています*5。段階的に価値を積み上げながら、テスト・運用・監視の知見を次のウェーブへ反映できる点がメリットです*5。
移行は内製と外注のどちらで進めるべきですか。
Discoveryからカットオーバーまでの工程には、BizTalk ServerとAzure Logic Apps Standard双方の専門知識、Scrumでのプロジェクト運営、Well-Architected Frameworkに基づく設計手法などが必要です*5。自社にこれらの知見を持つ人材が十分に揃っていない場合は、専門パートナーへの外注によってリスクを抑えながら進める選択肢を検討する価値があるでしょう。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Microsoft Learn「BizTalk Server 2020 – Microsoft Lifecycle」（https://learn.microsoft.com/en-us/lifecycle/products/biztalk-server-2020）
- *2 出典：Microsoft Learn「Mainstream support extended for BizTalk Server 2020 and Host Integration Server 2020」（https://learn.microsoft.com/en-us/lifecycle/announcements/biztalk-server-2020-host-integration-server-2020-support-extended）
- *3 出典：Microsoft Learn「BizTalk Server 2016 – Microsoft Lifecycle」（https://learn.microsoft.com/en-us/lifecycle/products/biztalk-server-2016）
- *4 出典：Microsoft Learn「Why Move from BizTalk Server to Azure Logic Apps Standard?」（https://learn.microsoft.com/en-us/azure/logic-apps/biztalk-server-migration-overview）
- *5 出典：Microsoft Learn「Migration Approaches for BizTalk Server to Azure Logic Apps」（https://learn.microsoft.com/en-us/azure/logic-apps/biztalk-server-migration-approaches）
