SAP ECCの保守は2027年12月31日に終了：止まるのではなく、価格が上がる

サーバールームで青いパッチケーブルがつながったネットワークラック

2027年12月31日、SAPはSAP ECC 6.0をはじめとするSAP Business Suite 7のコアアプリケーションのメインストリームメンテナンスを終了します。2028年1月1日に何かが止まるわけではありません。システムは動き続け、ユーザーは請求書の計上を続け、SAPも引き続きサポートを販売します。変わるのは、そのサポートにいくら払い、何が得られるかです。

この区別は重要です。出回っている助言の多くは、2027年を崖のように扱っているからです。ECCに残っているほとんどの企業にとって、そうではありませんし、本人たちもそれを分かっています。ECCの残存ユーザーで最も大きな層は、2030年に向けて計画しています。本当のリスクは別のところにあります。実際に日付を決める作業（アドオンのABAP、インターフェース、データ）の範囲確定が遅れ、2030年が2027年と同じくらい窮屈になることです。

この記事は、いまもECCを運用していて、この先3年をどうするかを決めなければならない中堅企業のCIOとSAP責任者、その多くはドイツ語圏の市場の企業に向けたものです。

SAPが実際に約束したこと

条件はSAPの保守戦略のページに載っており、最初に発表されたのは2020年2月です。

2027年12月31日まで：SAP ERP 6.0を含むBusiness Suite 7のコアアプリケーションについて、最新の3つのエンハンスメントパッケージを対象とするメインストリームメンテナンス。システムがそれより古いエンハンスメントパッケージなら、2027年の日付を前提に計画を立てる前に、（同じページからリンクされている）SAP Note 2881788を確認してください。
2028年1月1日から2030年12月31日まで：任意の延長メンテナンスで、「保守基準額に対して2パーセントポイントの割増」となります。簡単に言えば、いま払っている保守料率が2ポイント上がります。
延長メンテナンスを選ばない場合：自動的にカスタマースペシフィックメンテナンスに移ります。その範囲は、同じページからリンクされているSAP Note 52505に書かれています。それで十分だと決めつける前に読んでください。
S/4HANAについて：SAPは2040年末までの保守を約束しています。

より小さな層向けには、もう1つの道があります。SAPは2025年8月に、SAP ERP, private editionのtransition optionを示しました。SAPのプライベートクラウドの中で、2031年から2033年までECCを延命させる期間限定のサブスクリプションです。条件は厳格です。「システムは2030年12月31日より前に、SAP HANA上のSAP ERP, private editionに移行しなければならない」。サポートされるデータベースはHANAだけで、このオプションは2031年から2033年のmax success planとセットでしか提供されず、SAPはこのオプションで契約するシステムに2 TBの最低規模を設けています。SAPは、これが「最大規模で最も複雑なSAP ERPのお客様」向けだとしています。SAPが提示した「商業的に同等の条件」は、2025年末までにprivate editionを確約した顧客向けのものでした。

どのレベルを選ぶにしても、SAPとパートナーに書面で1つ質問してください。どの法改正（税、給与計算、電子インボイスのフォーマット）が、いつまでECCのシステムに届くのか、です。ドイツの企業にとっては、その答えだけで、とどまることが現実的かどうかが決まることもあります。

市場のほかの企業の動き

ドイツ語圏のSAPユーザー会であるDSAGは、2025年12月8日から2026年1月21日にかけて198の回答者を対象にInvestment Report 2026を実施しました。そのうち54%がいまもECCまたはそれより古いBusiness Suiteを運用しており、2024年の68%から下がっています。

時期については、回答者のほぼ半数が2030年末までにS/4HANAへ移行する計画で、DSAGは、これは延長メンテナンスの費用を払うことを意味すると指摘しています。さらに37%は2027年末までの移行を望んでおり、2033年とprivate editionのtransition optionを目指しているのは4%にすぎません。

DSAGのイェンス・フンガースハウゼン議長は、理由をはっきり述べています。スキル不足、並行する変革プロジェクト、限られた予算がスケジュールを後ろに押しており、「たとえ保守費用が高くなっても」そうなっている、ということです。

公共の発注者も動いています。EUの公共入札公告を当社が独自に数えたところ、2025年と2026年を通じて半年ごとにおよそ200件のS/4HANA移行の調達手続があり、2026年は10月初めまでに300件を超えており、その大半がドイツでした。作業は進んでいます。ただ、2027年の見出しが示唆するより長い期間に広がっているのです。

作業が実際にあるところ

ECCからS/4HANAへの技術的なコンバージョンは、SAPとそのパートナーのツールで十分に支えられています。カスタマイズが少なく、標準的なインターフェースがいくつかあるだけのECCなら、インテグレーターは何度もこれを経験しており、以下の大半は自社の問題ではありません。

自社の問題になる度合いは、自社でどれだけ作り込んできたかに比例します。

アドオンのABAP：プロジェクトが遅れる場所

S/4HANAは、新しいデータベースに載せたECCではありません。データモデルの一部が変わっています。得意先と仕入先はビジネスパートナーになります。財務と在庫の転記は、より少なく、より幅の広いテーブルに統合されました。一部のトランザクションと機能は削除されるか、置き換えられました。

テーブルを直接読むアドオン、移動したユーザーエグジットに依存しているアドオン、暗黙のうちにソート順を前提にしているアドオン（HANAは、クエリが求めない限りソート順を保証しません）は、構文チェックを通っても間違ったことをする可能性があります。痛いのはこの最後の種類です。コードスキャンではなく、統合テストや本番稼働後に表に出るからです。

うまくいく進め方は次のとおりです。

まず利用状況を測る。 本番環境で利用状況のログ（ABAPコールモニター、トランザクションSCMON）を有効にし、年度末の決算を丸ごと含む期間、動かし続けます。長く使われてきたシステムでは、アドオンのオブジェクトのかなりの割合が一度も実行されていないことがよくあります。誰も実行しないコードは移行せず、削除します。
残ったものに分析ツールをかける。 SAPのチェックは、問題の候補を見つけます。そのどれが業務にとって重要かは教えてくれません。
すべてのオブジェクトを分類する。 廃止するか、標準機能で置き換えるか、その場で直すか、コアの外で作り直すかです。オブジェクトごとに1つの決定を下し、業務側の責任者を指名します。
オブジェクトごとではなく、プロセスごとにテストする。 コードを変えるのは安い部分です。受注から入金までのプロセスや月次決算が同じ数字を出し続けることを証明するのが、高くつく部分です。

プロジェクトがここで遅れる理由は退屈なものです。早い段階で誰も数えなかったからです。アドオンの量はおおよそしか分からず、書いた人はすでに辞めていることが多く、本当の発見は社内で日付が発表された後の2回目のテストサイクルでやってきます。

インターフェースと、同じ時計で動くPI/PO

ECCが単独で動いていることはまれです。倉庫へのIDoc、工場の現場からのRFCやBAPIの呼び出し、銀行や税理士への固定長ファイル、2011年に誰かが作ったデータベースビューを読む顧客ポータル。そのどれもを見つけ出し、テストし、場合によっては作り直さなければなりません。

それらのインターフェースがSAP Process IntegrationやProcess Orchestrationを通っているなら、同じ日付にもう1つの期限があります。SAPのArchitecture Centerは、PI/POが「2027年の標準保守の終了」に近づいており、顧客は2030年まで保守を延長でき、その後はSAPのサポートが終わるとしています。SAPはPI/POの顧客をSAP Integration Suiteに誘導しており、移行アセスメントとウィザード形式の移行ツールが用意されています。

ツールは標準のオブジェクトには役立ちます。どのインターフェースがまだ何かの役に立っているかは教えてくれず、独自のマッピングロジックは依然として人が読む必要があります。棚卸しは、アンケートではなく、ミドルウェアの設定、ログ、スケジュールされたジョブから作ってください。そのうえで、ERPの移行とミドルウェアの移行を一緒に計画します。順番にやれば、すべてのインターフェースを2回テストすることになります。

データ移行

システムコンバージョンでは、データはシステムと一緒に移り、その品質もそのまま移ります。最初にぶつかるのはたいていビジネスパートナーへの変換です。重複した得意先、得意先でもある仕入先、自由テキストの項目に入った住所、間違った場所にある税番号。そのすべてを、コンバージョンの最中ではなく、その前に整備しなければなりません。

新規導入では、抽出、クレンジング、変換、ロードを行い、難しいのは照合です。経理が承認するのは、ロードのジョブが終わったときではなく、残高と未決済項目が一致したときです。移行は、だんだんきれいになっていくデータに対して何度でも実行でき、実行のたびに結果を自動で比較できる、繰り返し可能なコードとして作ってください。

どちらの道でも、もう必要のないものを先にアーカイブしてください。データが少なければ、コンバージョンの実行時間も、停止時間も短くなります。

クリーンコアの拡張

期限に追われるプロジェクトでは、すべての修正をそのまま持ち込み、後で片付けると約束したくなります。後は来ません。

その代わりになるものを、SAPはクリーンコアと呼んでいます。標準システムには手を入れず、SAPが公開して安定性を保っているインターフェースに対して拡張を作ることです。場所はS/4HANAの中でも、SAP Business Technology Platform上の隣でも構いません。初日からすべてをクリーンにはできません。実際に守れるルールはもっと単純です。新しいものは古いやり方では作らない、ということです。いま避けた修正の1つ1つが、将来のアップグレードのたびに再テストしなくて済む修正になります。

判断の枠組み

現実的な道は3つあり、あまり注目されない4つ目があります。

2027年12月31日までにS/4HANAで本番稼働する。 すでに着手していて、ほぼ標準的なシステムを運用し、パートナーを確保している企業に合う道です。今日から15か月で、年度末決算の最中の切り替えを受け入れる経理部門はほとんどありません。アドオンの分析が済んでいないなら、おそらくこの道ではありません。

延長メンテナンスの費用を払い、2030年までに本番稼働する。 市場の大半が向かっているのはこの道です。費用は2ポイントの割増です。期間の途中で本番稼働した場合にどう適用されるかは、SAPに確認してください。リスクは、2030年を2027年と同じように扱うことです。遠い先のことだと思っていたら、突然そうではなくなります。

private editionのtransition optionで2033年まで。 つまり、RISE with SAPの契約、HANA、2030年12月31日より前のSAP ERP, private editionへのシステム移行、max success plan、そして2 TBの最低規模です。中堅企業にとって、時間を買う方法として最も安いことはまれです。

SAPから離れる。 中堅の製造業者や卸売業者の一部にとっては、より小さなERPが現実的な選択肢です。インターフェースとデータの作業は小さくなりません。それがプロジェクトの大部分になります。

どれを選んでも、次の6か月にすること

今から2027年3月末までの間に、次のことはどの道を選んでも報われます。

出発点を確認する。 エンハンスメントパッケージ、データベース、保守契約です。自社に適用される延長メンテナンスの条件を、SAPのアカウントチームに書面で尋ねてください。
いますぐ利用状況のログを有効にする。 2026年度末の決算を記録できるようにします。
アドオンの分析を実行し、印象ではなく数字を得る。オブジェクトはいくつあり、そのうちいくつが使われていて、いくつがデータモデルの変更部分に触れているか。
インターフェースの棚卸しを作る。 PI/POを通るものもすべて含め、インターフェースごとに責任者と決定を割り当てます。
マスタデータのクレンジングを始める。 得意先と仕入先から始めます。
修正を増やすのをやめる。 今日から、新しい開発はクリーンコアに従います。
2028年の保守費の上乗せを2027年の予算に入れる。 不意打ちではなく、既知の費用として扱います。
体制を押さえる。 パートナー、社内のSAPチーム、そしてSAPの周りのシステムを見ている開発者です。スキル不足は、DSAGの会員がスケジュールの遅れの理由として挙げているものの1つです。

2030年の本番稼働から逆算すると、2030年にテストサイクルと切り替えのリハーサル、2029年に構築と改修、2028年に設計とデータのクレンジング、そしていまが分析です。見た目ほどの余裕はありません。

ご相談先

当社はSAPの機能コンサルティング会社ではなく、S/4HANAのコンバージョンを請け負ってはいません。それを行うパートナーの隣で、インターフェースの棚卸しと作り直し、データ移行のコードとその照合、そして移行を生き延びなければならないECCの周りのアプリケーションを担当します。その仕事はERPモダナイゼーションのページで、移行するまで現状のまま残るシステムについてはレガシーシステムの保守でご説明しています。プログラムに署名する前にERPの周辺資産を数えておきたいなら、office@c9group.devまでご連絡ください。