SAPシステムのアップグレードにおいて、ダウンタイムの正確な予測は多くの企業が抱える課題です。データ量だけで単純計算できない理由は、インフラ性能やアドオンの量、移行方式、そしてエンジニアの対応力など、複数の変動要素が複雑に絡み合うためです。本記事では、SAPアップグレードのダウンタイムを左右する5つの主要因を徹底解説します。最後までお読みいただくことで、自社のシステム環境に合わせた最適な移行計画を立てるための具体的なヒントが得られます。

SAPアップグレードのダウンタイムはなぜ「単純計算」できないのか？

SAPシステムのアップグレードやマイグレーションを計画する際、多くのプロジェクトマネージャーやIT担当者が直面するのが、「システムの停止時間はどのくらいになるのか」という疑問です。しかし、この問いに対して過去の事例や他社の実績から一律の回答を導き出すことは極めて困難です。なぜなら、SAPのダウンタイムは単純な計算式で算出できるものではないからです。

企業ごとのシステム環境と利用状況の多様性

SAPは企業の基幹業務を支える中核システムであり、その利用形態や構築の歴史は企業ごとに全く異なります。稼働年数に伴うデータの蓄積量、自社業務に合わせたカスタマイズの度合い、導入しているモジュールなど、あらゆる要素が複雑に絡み合っています。

例えば、同じデータ容量を持つシステムであっても、トランザクションデータが均等に分散している場合と、特定の巨大テーブルにデータが集中している場合とでは、データ変換や移行にかかる時間が大きく変動します。このように、表面的な数値だけでは測れない内部構造の違いが、単純計算を阻む大きな要因となっています。

ダウンタイムを左右する複雑な要因

SAPアップグレードのダウンタイムが予測しづらい理由として、主に以下の要素が挙げられます。

これらの要素は単独で影響するのではなく、相互に作用し合って最終的なダウンタイムを決定します。下表のとおり、各要因がどのようにアップグレードのプロセスに影響を及ぼすかを整理しました。

「平均的なダウンタイム」という罠

ベンダーや関連書籍で示される「平均的なダウンタイム」は、あくまで特定の条件下で行われたテスト環境や、理想的なプロジェクトの参考値に過ぎません。実際のプロジェクトにおいては、自社のシステム環境を詳細にアセスメントし、実機を用いたリハーサル（テストラン）を繰り返すことでしか、正確なダウンタイムを把握することはできません。

つまり、SAPアップグレードにおけるダウンタイムの算出とは、単純な足し算や掛け算ではなく、システム全体のアーキテクチャとビジネス要件を総合的に分析し、実証していくプロセスそのものなのです。

インフラ能力の真実：メモリよりも「CPUコア単体の処理性能」が鍵

SAPシステムのアップグレードやパッチ適用において、インフラリソースのサイジングは非常に重要です。多くのプロジェクトでは「とりあえずメモリを増やせば処理が速くなる」と誤解されがちですが、アップグレード処理の一部では、CPUコア単体の処理性能、つまりクロック周波数やシングルスレッド性能が処理時間に大きく影響します。

メモリ増設がダウンタイム短縮の「特効薬」にならない理由

SAP HANAなどのインメモリデータベースの普及により、メモリ容量の重要性は広く認知されています。しかし、アップグレードツールであるSUM（Software Update Manager）の動作において、メモリは一定量（推奨要件）を満たしていれば、それ以上の増設が処理速度の劇的な向上に直結するわけではありません。

CPUコア単体の処理性能がアップグレード時間に影響するメカニズム

アップグレードのダウンタイム中には、テーブル変換、インデックスの再構築、リポジトリオブジェクトの切替や有効化など、SUM本体の処理が実行されます。これらの処理の中には、順次的に進行するものや、特定の処理単位がボトルネックとなるものがあります。このような場面では、CPUコア単体の処理性能、すなわちクロック周波数やシングルスレッド性能が処理時間に影響します。

単一コア性能（クロック周波数）の重要性

並列化できない順次処理のフェーズや、巨大な単一テーブルの変換処理においては、CPUの単一コア性能がそのまま処理時間に直結します。順次処理のフェーズや、特定の大規模テーブルに対する変換処理では、CPUコア単体の処理性能が処理時間に大きく影響します。アップグレード時のダウンタイム短縮を検討する際には、1コアあたりの処理性能、すなわちクロック周波数やシングルスレッド性能を重視してください。

インフラリソースの役割とアップグレードへの影響度

アップグレード処理における各インフラリソースの役割と、ダウンタイムへの影響度を整理すると下表のとおりです。

このように、SAPアップグレードのダウンタイムを最小化するためには、十分なメモリの確保を前提とした上で、CPUコア単体の処理性能を重視することがインフラ戦略の要となります。クラウド環境を利用している場合は、アップグレード期間中のみCPUコア単体の性能が高いインスタンスタイプへ一時的に変更することも有効です。その際は、クロック周波数やシングルスレッド性能、ストレージI/O性能とのバランスを踏まえて選定してください。

プロダクト特有の変動要素：SPスタックとアドオンの影響

SAPシステムのアップグレードにおいて、ダウンタイムの長さを大きく左右するのがSAPプロダクト自体の状態です。とくに、適用するサポートパッケージ（以下、SP）スタックの差分や、独自に開発したアドオンプログラムの量は、処理時間に直結する重要な要素となります。

SPスタックの適用量とダウンタイムの関係

現在のシステムバージョンと、ターゲットとなるバージョンとの間にどれだけの開きがあるかは、ダウンタイムを予測するうえで非常に重要です。

バージョンの差が大きいほど、適用すべきSPスタックの量が増加し、それに伴ってディクショナリの有効化やテーブルの変換処理に要する時間が長くなります。適用差分が大きいほど、オブジェクトの有効化やテーブル変換などの処理対象が増えるため、アップグレードに要する処理時間は増加する傾向があります。

アドオンプログラムとモディフィケーションの影響

SAPの標準機能を補完するために開発されたアドオンプログラムや、標準オブジェクトに対するモディフィケーション（直接変更）も、ダウンタイムの変動要素として無視できません。

アドオンテーブルの構造変更や、大量のデータが格納されたカスタムテーブルの変換処理が発生する場合、ダウンタイム中のデータ移行フェーズに多大な時間を要します。影響を及ぼす主な要因は以下のとおりです。

これらの要素がどのようにダウンタイムに影響するかは、下表のとおりです。

SPAUとSPDDフェーズでの調整作業

アップグレードプロセスにおいて、ディクショナリオブジェクトの調整を行うSPDDと、リポジトリオブジェクトの調整を行うSPAUは、システムダウンタイム中、またはその前後に確実に対応しなければならない重要なフェーズです。

モディフィケーションが多いシステムでは、この調整作業が複雑化し、結果として全体の作業時間が長引く原因となります。事前の検証環境でのアップグレードを通じて、これらの調整内容を移送依頼として記録しておくことで、本番環境でのダウンタイムを短縮することが可能です。

SAP S/4HANAへのコンバージョンにおける特記事項

SAP S/4HANAコンバージョンでは、Universal Journalへの移行など、S/4HANAのデータモデルに合わせた変換・移行作業が発生します。

一方で、得意先・仕入先マスタをBusiness Partnerへ統合するCVI（Customer/Vendor Integration）は、コンバージョン中のダウンタイム処理ではありません。CVIはS/4HANAコンバージョンの前提条件として、事前にECC側で準備・同期・整合性解消を完了させておく必要があります。

そのため、CVIの対応状況はコンバージョン計画全体に大きく影響しますが、ダウンタイム中のデータ変換処理とは分けて考える必要があります。

SUMのScenario Strategy：StandardとDowntime-optimizedの違い

SAPシステムのアップグレードやコンバージョンでは、Software Update Manager（SUM）のScenario Strategy選択が、技術的ダウンタイムや必要リソース、作業の複雑性に大きく影響します。

本記事では、SUMのStrategyをStandardとDowntime-optimizedの2つに絞って説明します。StandardはSUMの標準的な方式であり、Downtime-optimizedは技術的ダウンタイムの短縮を重視する方式です。

どちらを選択すべきかは、業務停止可能時間、利用可能なシステムリソース、対象シナリオ、データ量、アドオンの状況、リハーサル結果を踏まえて判断する必要があります。

Downtime-optimizedの特徴

Downtime-optimizedは、SUMにおいて技術的ダウンタイムの短縮を目的として選択される方式です。

この方式では、通常であればダウンタイム中に実行される処理の一部を、可能な範囲でuptime中に前倒しして実行します。

SAP S/4HANAへのシステムコンバージョンでは、データ変換や、DMOを併用する場合の一部データ移行処理をuptime側へ移すことで、技術的ダウンタイムの短縮を図ります。

一方で、Downtime-optimizedは単に停止時間を短くできる便利な選択肢ではありません。追加の事前準備、影響分析、リハーサル、業務制約の確認が必要となり、プロジェクト全体の計画はStandardより複雑になります。

Standardの特徴

Standardは、SUMにおける標準的な方式です。

Downtime-optimizedのように追加のダウンタイム短縮機能を積極的に使用する方式ではありません。ただし、「すべての処理をダウンタイム中に実行する方式」や「シャドウシステムを使用しない方式」というわけでもありません。

Standardでは、SUMの通常フローに従って、uptime中の前処理、Preprocessing、必要な調整作業、Downtime中の切替処理などを進めます。

ダウンタイム短縮の度合いはDowntime-optimizedほど高くありませんが、プロセスの複雑性を抑えつつ、現行SUMの標準的な手順で進められる点が特徴です。

自社に最適な戦略の選び方

Strategyの選定では、単に「ダウンタイムを短くしたい」という観点だけで判断してはいけません。

StandardとDowntime-optimizedのどちらを選ぶかは、業務停止可能時間、利用可能なシステムリソース、対象シナリオ、SUMバージョン、データ量、アドオンの状況、リハーサル結果を踏まえて判断します。

停止可能時間に一定の余裕があり、現行SUMの標準的な流れで進めたい場合はStandardが基本選択肢になります。

一方、停止可能時間が厳しく、技術的ダウンタイムを短縮する必要がある場合はDowntime-optimizedを検討します。ただし、適用条件や業務影響、追加の事前準備を十分に確認する必要があります。

最大の不確定要素：エンジニアのスキルと「未知の不具合」への対応力

SAPアップグレードプロジェクトにおいて、ハードウェアのスペックや選択した移行方式以上にダウンタイムを左右するのが、実行を担うエンジニアのスキルと、予期せぬトラブルへの対応力です。どれほど綿密に計画を立てても、アップグレード作業中に未知の不具合が発生するリスクをゼロにすることはできません。

SAPアップグレードにおける「未知の不具合」の正体

SAPシステムのアップグレードには、標準の移行ツールであるSoftware Update Manager (SUM)が広く利用されます。しかし、各企業でカスタマイズされた環境や、適用されているアドオン、OSやデータベースのバージョンといった組み合わせは千差万別であり、ツールが途中で停止するエラーが頻発します。

具体的には、以下のような事象が「未知の不具合」としてダウンタイムを延長させる要因となります。

トラブルシューティングを左右するエンジニアのスキルセット

不具合が発生した際、いかに迅速に原因を特定し、解決策を講じられるかがダウンタイムの長さを決定づけます。エラーメッセージから原因を推測し、膨大なSAP Notesから適切な解決策を見つけ出す能力は、一朝一夕に身につくものではありません。下表のとおり、エンジニアに求められるスキルセットは多岐にわたります。

ダウンタイム延長を防ぐための「リハーサル」の重要性

本番環境でのダウンタイムを最小限に抑えるためには、事前のテスト環境を用いたリハーサル（ドライラン）が不可欠です。本番環境と同等のデータ量と構成でテストを繰り返し、発生しうる不具合を事前に洗い出して手順書に反映することが、最も確実なリスクヘッジとなります。

リハーサルを通じてエンジニアチームがシステムの癖を把握し、エラー発生時のエスカレーションフローを確立しておくことで、本番移行時の「未知の不具合」を「既知の対応可能事項」へと変換することができます。結果として、予期せぬダウンタイムの延長を劇的に減らすことが可能です。

よくある質問

SAPアップグレードのダウンタイムは平均してどのくらいですか？

SAPシステムのアップグレードにかかるダウンタイムは、対象シナリオによって大きく異なります。単純なハードウェアリプレースやSAP ERP 6.0へのEHP適用など、比較的シンプルなケースでは、週末の業務停止時間を利用し、48時間以内を目標に計画されることもあります。

一方、SAP S/4HANA Cloud Private Editionへの移行やRISE with SAPを伴う移行では、システム変換、データ移行、接続切替、周辺システム連携確認、業務検証が連続して発生します。そのため、週末48時間以内を前提にするのではなく、年末年始や大型連休など、数日単位のまとまった停止期間を本番移行の候補として検討することが一般的です。

実際の停止期間は、リハーサル結果と業務側の確認範囲を踏まえて判断する必要があります。

ダウンタイムの変動要因を整理すると、下表のとおりです。

ダウンタイムを極限まで短縮する「ZDO（Zero Downtime Option）」とは何ですか？

ZDO（Zero Downtime Option）は、SUMで提供されるダウンタイム最適化手法の一つです。主にSAP S/4HANAシステムのアップグレードやアップデートを対象とする方式であり、リリースアップグレード、Feature Package Stack、Support Package Stackの適用などで、技術的ダウンタイムを極小化する目的で検討されます。

一方で、ECCからSAP S/4HANAへのシステムコンバージョンにZDOを適用するものではありません。ECCからS/4HANAへのコンバージョンでダウンタイム短縮を検討する場合は、Downtime-optimized Conversionや、DMOを利用する場合のDowntime-optimized DMOといったアプローチを検討します。

ZDOの適用可否は、対象リリース、SUMバージョン、アドオンの状況、業務制約、テーブル更新の影響などによって変わります。そのため、導入を検討する場合は、SAP公式ガイドや関連SAP Noteを確認し、本番同等環境でリハーサルを実施する必要があります。

クラウド環境への移行と同時にアップグレードを行う場合、ダウンタイムはどう変動しますか？

オンプレミスからクラウド環境への移行と、SAP S/4HANAなどへのアップグレードを同時に実施するアプローチは、DMO（Database Migration Option）with System Moveなどと呼ばれます。この場合、ネットワーク経由でのデータ転送時間という新たな変動要素が加わるため、オンプレミス内での単純なアップグレードと比較してダウンタイムが長期化する傾向があります。

ダウンタイムを抑えるためには、事前のネットワーク帯域の確保や、テスト移行を通じたデータ転送速度の正確な計測が不可欠です。

なお、ECCからSAP S/4HANAへのシステムコンバージョンや、クラウド移行を伴うコンバージョンでは、ZDOではなく、DMO、DMO with System Move、Downtime-optimized Conversion、Downtime-optimized DMOといった方式の適用可否を確認します。ZDOはS/4HANAシステムのアップグレード／アップデート向けの方式として、コンバージョンとは分けて整理する必要があります。

ダウンタイム中の業務停止範囲はどのように決定すべきですか？

ダウンタイム中の業務停止範囲は、IT部門だけで決定するのではなく、ビジネス部門との綿密な調整によって決定する必要があります。アップグレードの対象となるモジュールや連携する周辺システムへの影響を洗い出し、どの業務がどの期間停止するかを明確に定義します。

特に、月末や期末などの繁忙期を避けることはもちろん、万が一の切り戻しに備えたバッファ時間もダウンタイム計画に含めておくことが、プロジェクトを成功に導く重要なポイントです。

SAPプロダクト編：SAPアップグレードのダウンタイム変動要素に関するよくある質問

ダウンタイムの正確な事前予測はできますか？

データ量やアドオンなど多くの要素が絡むため、単純計算は困難です。精度の高い予測には、本番同等の環境でのテストランが不可欠です。

インフラ強化でダウンタイムは短縮できますか？

はい、短縮可能です。単にメモリを増設するだけでは効果が限定的な場合があります。アップグレード処理では、順次処理や単一処理フェーズがボトルネックとなることがあるため、CPUコア単体の処理性能、つまりクロック周波数やシングルスレッド性能を高めることが、処理時間の短縮に寄与します。

SUMのScenario Strategyはどのように選べばよいですか？

SUMのScenario Strategyは、StandardとDowntime-optimizedの違いを理解したうえで選定します。

一般的な選択肢はStandardです。技術的ダウンタイムを短縮する必要がある場合はDowntime-optimizedを検討しますが、適用条件、追加準備、業務制約、影響分析が必要です。

最終的には、業務停止可能時間、システムリソース、対象シナリオ、データ量、アドオンの状況、リハーサル結果をもとに判断する必要があります。

まとめ：ダウンタイムを左右する5つの柱

SAPアップグレードのダウンタイムは、CPUコア単体の処理性能、アドオンの状況、SUMのScenario Strategy選択、エンジニアのスキル、未知の不具合への対応力という5つの柱によって大きく変動します。

また、ZDO、Downtime-optimized Conversion、DMOはそれぞれ適用対象が異なります。アップグレード、アップデート、システムコンバージョン、クラウド移行を混同せず、対象シナリオに応じて適切な方式を選定することが重要です。

これらを総合的に評価し、入念な事前検証を行うことがプロジェクト成功の鍵となります。

当社はSAPのスペシャリストとして、豊富な知見と実績をもとに、最適なソリューションをご提案します。SAPに関するご相談やお見積りのご依頼は、ぜひお気軽にリアルテックジャパンにお問い合わせください。

関連記事はこちら
第2回：SAPアップグレードのダウンタイムを左右するハードウェア性能｜CPU並列数とR3transの最適解
第3回：SAPアップグレードのダウンタイムを左右するテーブル変換（PARCONV_UPG）｜発生条件と影響範囲の見極め方