LASSIC Media らしくメディア
System Center終了、移行と外注の判断軸
LASSIC IT事業部|元請(プライムベンダー)としてシステム保守・運用を受託
この記事のポイント
- System Center 2016(Operations Manager等)は延長サポートが2027年1月11日に終了予定で、2019は2029年4月9日、2022は2032年4月13日と、世代ごとに終了日が異なります。
- Configuration Manager(旧SCCM/MECM)はSystem Centerの固定リリースとは別の「現在のブランチ」モデルで動いており、共同管理(Co-management)によりMicrosoft Intuneへ段階的に機能を移せます。
- Operations Managerのクラウド延長だったSCOM Managed Instanceは2026年9月30日までに廃止予定と案内されており、Azure Monitorへの移行に標準的な自動変換ツールはない点にも注意が必要です。
目次
- System Centerとは?主要コンポーネントとConfiguration Managerの位置づけ
- System Center 2016/2019/2022のサポート終了日を公式ライフサイクルで確認する
- Configuration Manager(旧SCCM/MECM)はSystem Centerの固定リリースと別軸で動く
- 共同管理(Co-management)でConfiguration ManagerからMicrosoft Intuneへ段階移行する仕組み
- Operations Manager等の後継検討とAzure Monitor移行で押さえておきたい注意点
- サポート終了を放置した場合に生じるリスク
- 内製移行と外注委託のコスト構造比較
- 移行プロジェクトの標準的な進め方
- まとめ:System Center移行の3つの判断軸
- よくある質問
System Centerとは?主要コンポーネントとConfiguration Managerの位置づけ
System Centerとは、Microsoftが提供するオンプレミス向けの統合管理製品群の総称です。クライアントPCやサーバーの構成管理を担うConfiguration Manager(旧称System Center Configuration Manager、SCCM)、監視を担うOperations Manager、仮想化基盤を管理するVirtual Machine Manager、ITサービス管理のService Manager、自動化のOrchestrator、バックアップのData Protection Managerなど、複数のコンポーネントで構成されています。
これらのうちOperations Manager・Virtual Machine Manager・Service Manager・Orchestrator・Data Protection Managerは、「System Center 2016」「System Center 2019」「System Center 2022」といった数年おきの固定バージョンとしてリリースされ、それぞれ個別のサポート終了日を持つ固定ライフサイクルポリシーが適用されます*6。一方でConfiguration Managerは、System Centerのこの固定リリースの枠組みから切り離され、独自の継続的な更新モデルで提供されている点が大きな違いです*6。この違いを理解しないまま「System Centerのサポート終了日」を一括りに調べると、コンポーネントごとの実際の期限を取り違えるおそれがあります。
System Center 2016/2019/2022のサポート終了日を公式ライフサイクルで確認する
Microsoft Learnのライフサイクル情報によると、System Center 2016 Operations Managerは2016年10月28日に提供が始まり、メインストリームサポートは2022年1月11日に終了済みで、延長サポートは2027年1月11日に終了する予定です*1。本稿執筆時点(2026年7月)で、延長サポート終了まで半年程度に迫っています。
System Center 2019 Operations Managerは2019年3月14日提供開始で、メインストリームサポートは2024年4月9日にすでに終了しており、延長サポートは2029年4月9日までです*2。System Center 2022 Operations Managerは2022年4月1日提供開始で、メインストリームサポートは2027年4月13日、延長サポートは2032年4月13日までとなっています*3。いずれも固定ライフサイクルポリシーが適用される製品で、日程は米国太平洋時間(PT、レドモンド基準)で表示されている点に注意が必要です*1*2*3。
ここで紹介した日程はOperations Managerのものですが、Virtual Machine Manager・Service Manager・Orchestrator・Data Protection Managerなど同一世代の他コンポーネントについても、個別のライフサイクルページで終了日を確認することをおすすめします。世代(2016/2019/2022)が同じでもコンポーネントごとにページが分かれているため、自社が利用している具体的なコンポーネント名で検索し、公式情報を都度確認する姿勢が欠かせません。
Configuration Manager(旧SCCM/MECM)はSystem Centerの固定リリースと別軸で動く
Configuration Managerは、2015年12月から継続して提供されている「現在のブランチ(current branch)」というモデルで更新され続けており、Modern Lifecycle Policyが適用されています*4。System Centerの2016/2019/2022のような数年おきの固定バージョンとは異なり、年に数回リリースされる各バージョンが、それぞれ提供開始から18か月間サポートされる仕組みです*5。
公式ドキュメントは、各バージョンのサポート期間を「セキュリティ更新プログラムと緊急更新プログラムの提供期間(最初の4か月程度)」と「セキュリティ更新プログラムのみの提供期間(残りの期間)」の2段階に分けて説明しています*5。最新バージョンを適用していない環境では、不具合修正を含む緊急更新プログラムを受け取れない場合がある点も明記されており*5、定期的なバージョン更新を運用に組み込む必要があります。なお、2303以降は製品名が「Microsoft Endpoint Configuration Manager」から「Microsoft Configuration Manager」へと変更されています*4。
System Center公式ドキュメントは「Configuration Managerは(System Centerの)2019リリースの変更による影響を受けず、現在のブランチのリリースサイクルを継続する」と明記しており*6、Configuration Managerのサポート状況を調べる際はSystem Center 2016/2019/2022のページではなく、Configuration Manager専用のライフサイクルページを確認する必要があります*4。
共同管理(Co-management)でConfiguration ManagerからMicrosoft Intuneへ段階移行する仕組み
Microsoft公式ドキュメントは、共同管理(Co-management)を「Configuration ManagerとMicrosoft Intuneの両方を使ってWindowsデバイスを同時に管理できる仕組み」と説明しています*7。共同管理を有効にすると、コンプライアンスポリシー・Windows Updateポリシー・リソースアクセスポリシー・エンドポイント保護・デバイス構成・Office Click-to-Runアプリ・クライアントアプリという複数のワークロードについて、管理の主導権をConfiguration ManagerからIntuneへ、ワークロード単位で個別に切り替えられます*7。
共同管理へ至る経路は、既存のConfiguration Managerクライアントをハイブリッド Microsoft Entra参加させたうえでIntuneへ登録する方法と、新規のインターネット接続デバイスをMicrosoft Entra参加させて自動的にIntuneへ登録する方法の2通りが案内されています*7。前提条件としてMicrosoft Entra ID P1またはP2のライセンス、Configuration Manager現在のブランチの対応バージョン、Windows Autopilot対応のWindowsバージョンなどが必要です*7。一括ですべてを切り替える必要はなく、一部のデバイス群でパイロット運用しながら段階的に移行できる設計になっている点は、既存投資を活かしたい企業にとって扱いやすい要素と言えるでしょう*7。
Operations Manager等の後継検討とAzure Monitor移行で押さえておきたい注意点
Operations Managerの監視機能をクラウドへ寄せる選択肢として、Azure Monitor SCOM Managed Instanceというサービスが提供されていました。しかし公式ページには「Azure Monitor SCOM Managed Instanceはサポートを終了しており、2026年9月30日までに廃止予定である」との注記が明記されています*8。同ページはAzure Monitorへの移行、またはSystem Center Operations Managerの継続利用のいずれかを代替案として案内しており*8、Operations Managerのクラウド後継を検討する際は、この廃止予定を踏まえて選択肢を組み立てる必要があります。
Azure Monitorへの移行については、公式ガイドが「System Center Operations Managerからの標準的な移行手順は存在しない」としたうえで、オンプレミスとクラウドを併用する「ハイブリッドクラウド監視」戦略を案内しています*9。具体的には、Azure Monitor エージェントとOperations Managerのエージェントを同一マシンに共存させる方法や、SCOM管理グループをAzure Monitorへ接続してデータを転送する方法が挙げられています*9。ただし、SCOMの管理パックをAzure Monitorへ自動変換するツールは存在しないと明記されており*9、監視ルールの移行は個別の分析と再設計を伴う作業になります。
サポート終了を放置した場合に生じるリスク
延長サポートが終了すると、新たに発見された脆弱性に対するセキュリティ更新プログラムと、Microsoftへの技術サポート依頼が提供されなくなります*1*2*3。Configuration Managerについても、18か月の支援期間を過ぎたバージョンは、電話やオンラインでの技術サポートを受けられなくなる一方、対応バージョンへのアップグレード支援だけは継続すると案内されています*5。
社内の端末管理や監視基盤として日常的に稼働しているシステムがこの状態のまま放置されると、脆弱性が修正されないリスクにさらされ続けます。加えてConfiguration Managerの現在のブランチでは、2603バージョンの解説ページに「特定の内部サービスが2026年10月に非推奨となり、共同管理環境でIntuneがコンプライアンスワークロードを管理している場合、Software Centerでのコンプライアンスチェックが失敗する可能性がある」との記載があり*5、バージョンを更新しないままでいると想定外の機能不全に気づきにくいという副次的なリスクも生じます。
内製移行と外注委託のコスト構造比較
System Centerの各コンポーネントについて、どの後継へどう移行するかを検討する際、内製で進めるか外部パートナーへ委託するかによって、必要な体制とリスクの重心が変わります。以下の表に主な違いを整理しました。
| 比較項目 | 内製移行 | 外注委託 |
|---|---|---|
| 現状把握・棚卸し | コンポーネントごとのバージョン・終了日・利用ワークロードを自社で洗い出します*1*2*3 | 複数案件で培った棚卸しテンプレートを使って短期間で現状把握を進められます |
| 移行方式の判断 | 共同管理によるIntune移行か、Azure Monitorとの併用かを自社で調査・選定する必要があります*7*9 | 要件に応じて段階移行の順序やワークロード切替の計画を提案してもらえます |
| 監視ルール・管理パックの再設計 | 自動変換ツールがないため、既存の管理パックを分析し再設計する作業を自社で担います*9 | 監視要件の整理から新環境での再構築まで一貫して依頼できます |
| スケジュール管理 | 世代ごとに異なる終了日を踏まえた逆算計画を自社の担当者が兼務することが多くなります*1*2*3 | 移行プロジェクト専任の体制で、期限からの逆算スケジュールを管理してもらえます |
移行プロジェクトの標準的な進め方
移行先を問わず、プロジェクトはおおむね共通の段階を踏みます。第一に、現行System Center環境の棚卸しです。稼働中のコンポーネント(Configuration Manager・Operations Manager・Virtual Machine Manager等)ごとのバージョンと、それぞれの終了日を公式ライフサイクルページで確認します*1*2*3*4。
第二に、後継の選定です。Configuration Managerであれば共同管理を使ったIntuneへのワークロード移行*7、Operations Managerであれば継続利用かAzure Monitorとのハイブリッド監視かを検討します*8*9。第三に、パイロット運用です。一部のデバイス群や監視対象だけを先行して新方式へ切り替え、動作を確認しながら適用範囲を広げます*7。
第四に、本格移行と検証です。ワークロードの切替状況や監視データの収集状況を確認しながら、利用者への周知と旧環境の縮退を進めます。この一連の流れを、限られた社内リソースだけで期限内に完了できるかどうかが、内製・外注を判断する分かれ目になります。
まとめ:System Center移行の3つの判断軸
本稿ではSystem Centerの構成とサポート終了、クラウド後継への移行方法を、Microsoft公式情報に基づいて整理しました。要点は次の3つに集約されます。第一に、System Center 2016は延長サポートが2027年1月11日に終了予定であり、2019は2029年4月9日、2022は2032年4月13日と世代によって期限が異なるため、自社の利用コンポーネントとバージョンを正確に把握する必要があります*1*2*3。
第二に、Configuration Managerはこの固定リリースとは別の18か月サイクルで更新され続けており、共同管理を使えば一部機能から段階的にMicrosoft Intuneへ移せます*4*5*7。第三に、Operations Managerのクラウド延長だったSCOM Managed Instance自体が2026年9月30日までに廃止予定とされているため、Azure Monitorへの移行は自動変換ツールに頼れず、監視ルールの再設計を前提に計画する必要があります*8*9。専門知識を社内でどこまで確保できるかによって、内製と外注のどちらで進めるべきかが決まってくるでしょう。
よくある質問
System Centerのサポート終了日はコンポーネントによって違いますか。
はい。Operations Manager・Virtual Machine Manager等はSystem Center 2016/2019/2022という固定リリースの世代ごとに終了日が決まっており、System Center 2016は延長サポートが2027年1月11日、2019は2029年4月9日、2022は2032年4月13日までです。一方Configuration Managerは固定リリースの枠組みに含まれず、独自の現在のブランチモデルで18か月ごとにサポート期限を迎えます。自社が使うコンポーネント名で個別に公式ライフサイクルページを確認することをおすすめします。
Configuration ManagerはそのままMicrosoft Intuneに置き換わりますか。
一括で置き換わるものではありません。共同管理(Co-management)を有効にすると、コンプライアンスポリシーやWindows Updateポリシーなど特定のワークロード単位で、管理の主導権をConfiguration ManagerからIntuneへ段階的に切り替えられます。Configuration Managerは共同管理でサポートされない機能を含め、その他のワークロードの管理主体のままです。
Operations ManagerをそのままAzure Monitorへ移行できますか。
標準的な自動移行手順は用意されていません。Microsoft公式ガイドは、オンプレミスとクラウドを併用するハイブリッド監視戦略を案内しており、SCOMの管理パックをAzure Monitorへ変換するツールもない点が明記されています。監視ルールごとに必要性を分析し、段階的に置き換えていく計画を前提とすべきでしょう。
Azure Monitor SCOM Managed Instanceへ移行すればよいのではないですか。
Azure Monitor SCOM Managed Instance自体が、サポートを終了しており2026年9月30日までに廃止予定であると公式ページに明記されています。同ページはAzure Monitorへの移行かSystem Center Operations Managerの継続利用のいずれかを代替案として案内しており、SCOM Managed Instanceを新たな移行先として選ぶことは推奨されません。
サポート終了後もそのまま使い続けた場合、何が起きますか。
動作自体はすぐに止まりませんが、延長サポート終了後は新たに発見された脆弱性へのセキュリティ更新プログラムと、Microsoftへの技術サポート依頼が提供されなくなります。Configuration Managerについても、サポート期間を過ぎたバージョンは技術サポートを受けられず、対応バージョンへのアップグレード支援のみが案内される仕組みです。
著者:テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典:Microsoft Learn「System Center 2016 Operations Manager – Microsoft Lifecycle」(https://learn.microsoft.com/en-us/lifecycle/products/system-center-2016-operations-manager)
- *2 出典:Microsoft Learn「System Center 2019 Operations Manager – Microsoft Lifecycle」(https://learn.microsoft.com/en-us/lifecycle/products/system-center-2019-operations-manager)
- *3 出典:Microsoft Learn「System Center 2022 Operations Manager – Microsoft Lifecycle」(https://learn.microsoft.com/en-us/lifecycle/products/system-center-2022-operations-manager)
- *4 出典:Microsoft Learn「Microsoft Configuration Manager – Microsoft Lifecycle」(https://learn.microsoft.com/en-us/lifecycle/products/microsoft-configuration-manager)
- *5 出典:Microsoft Learn「Current branch versions – Configuration Manager」(https://learn.microsoft.com/en-us/intune/configmgr/core/servers/manage/current-branch-versions-supported)
- *6 出典:Microsoft Learn「Overview of System Center LTSC and SAC releases」(https://learn.microsoft.com/en-us/system-center/ltsc-and-sac-overview)
- *7 出典:Microsoft Learn「Co-management for Windows devices – Configuration Manager」(https://learn.microsoft.com/en-us/intune/configmgr/comanage/overview)
- *8 出典:Microsoft Learn「About Azure Monitor SCOM Managed Instance」(https://learn.microsoft.com/en-us/previous-versions/azure/azure-monitor/scom-manage-instance/overview)
- *9 出典:Microsoft Learn「Migrate from System Center Operations Manager (SCOM) to Azure Monitor」(https://learn.microsoft.com/en-us/azure/azure-monitor/fundamentals/azure-monitor-operations-manager)