クラウド

SAP BW からの移行 ― 失敗しないための7つの留意点

移行

2026.06.22

SAP BW から別のデータ分析基盤へ移行するプロジェクトは、単なるツールの入れ替えではありません。本稿は、主として非 SAP のデータ分析基盤へ移行するケースを想定しています。長年積み上げてきた業務知識・カスタマイズ・レポート資産をどう引き継ぎ、どう作り直すかという判断の連続です。本稿では、移行を成功させるために押さえておきたい7つのポイントを整理します。

1. 現行再現にとらわれない

移行でまず見直しておきたいのは、「いまの BW をそのまま新環境に移す」という発想です。BW からの完全移植は現実的ではありません。長年の運用で積み重なった多くのカスタマイズや暗黙知をそのまま再現しようとすれば、工数は膨大に膨らみ、しかも移行先ツールの強みを活かせなくなるリスクがあります。

むしろ移行は、「何のためのデータか」「何を意思決定に使うか」をゼロベースで問い直す絶好の機会と捉え、移行先ツールの特性を活かした「再設計」という姿勢こそが重要になります。特に BEx アナライザや Analysis for Office に依存した業務フローは、操作体系の変化を前提に再定義しておくべきです。

2. BW 独自機能への対応

BW には、他のツールでは標準で備わっていない独自機能があります。これらは移行時に必ず個別の対応方針を決めておく必要があります。代表的なものを挙げます。

非累計値（Non-Cumulative Key Figure）：在庫残高や口座残高のように、ある時点の値を保持するキー数値。移行先ではスナップショット設計や別途の集計ロジックが必要になる。
赤黒処理：BW が内部でデルタ差分（赤伝・黒伝）を生成する仕組み。移行先では ETL 側またはデータモデル側で差分計算ロジックを実装する必要がある。
時間依存マスタ：有効期間付きの属性で、組織変更後も過去時点の値で参照できる。移行先では、属性の変更履歴を世代ごとに保持するディメンション設計で実現する。
仮想プロバイダ / HANA View：リアルタイム集計や複数ソース統合の機能。移行先では仮想レイヤー（View / Semantic Layer 等）の設計で対応する。

3. 実装の写し取りが招くパフォーマンス課題

BW における機能の作りや配置をそのまま移行先ツールに写し取ろうとすると、パフォーマンス劣化が生じがちです。とりわけ、データの整形・加工をレポート側で行う実装は、クエリ応答時間の悪化を招きます。整形・加工は ETL・データモデル側で解決する設計を優先すべきです。

あわせて、以下の要件は早期に明確化しておきたいところです。

レポートのレイアウトおよび操作性（BEx / Analysis for Office 習熟ユーザーへの配慮が必要）
過去時点のマスタ値でのデータ参照（組織変更前の部門名でのスライス等）
参照可能な過去データの期間（移行対象範囲・ヒストリカルデータの取り扱い方針）

4. データ移行・検証の早期着手

移行データの整合性確認、そしてレポート表現・操作性の検証は、プロジェクト後半ではなく早期に着手すべきです。BW とのデータ突合（数値・件数・集計軸）をチェックする仕組みを用意し、ユーザー側にも早い段階で確認に参加いただきます。

特に決算・締め処理に関わるデータは、実際の業務サイクルを通じた検証が必要なため、時間的に余裕を持った計画が求められます。さらに、移行データの検証結果は「移行判定基準」として事前に定義しておくとよいでしょう（例：件数差異 0 件、金額差異 ±0 円等）。

5. データ不整合時のトレーサビリティ確保

不整合が発生した際に原因を迅速に追えるよう、実装段階から例えば次のような仕掛けを作り込んでおきます。

ロード日時・バッチ実行 ID をデータに付与し、いつ取り込まれたレコードかを特定できるようにする。
データソース識別子を保持し、どのシステム・ファイル・インタフェース経由で連携されたかを判別可能にする。
変換・加工の過程を記録するデータリネージ（系譜）の仕組みを検討する（ツールによっては標準機能として提供される）。
監査ログ・変更履歴を残す設計にしておけば、障害発生時の調査工数を大幅に削減できる。

6. BW と移行先の両方を熟知した技術者の参画

BW の概念（InfoProvider、DSO、Transformation、DTP 等）と移行先ツールの双方を理解している技術者が不在だと、設計上の誤りや手戻りが多発します。移行先ツールでは DB View・SQL・Semantic Layer による処理の比重が増す傾向があり、BW のような GUI ベースのモデリングとは異なるスキルセットが求められます。

モデリング概念の違いにも注意が必要です。BW では InfoCube・DSO・マスタデータといったオブジェクト体系で役割が分担されていますが、移行先では同等の機能が異なるレイヤーに分散・統合されることが多くあります。設計思想の違いを正しく理解したうえで、オブジェクトマッピングを行う必要があります。

7. その他の留意点

上記に加えて、プロジェクト計画の前提として次の3点も早期に確認・決定しておきたいところです。

ライセンス・サポート期限の確認：旧来の BW（NetWeaver 7.5 等）は標準保守が 2027 年（延長で 2030 年）、BW/4HANA は 2040 年が一つの目安。移行のタイムラインに直結するため早期確認が必要。
ユーザートレーニング・チェンジマネジメント：ツール刷新はエンドユーザーの習熟度に直結する。操作性変化に対するトレーニング計画と、現場の受容性を高めるコミュニケーション施策を並行して検討する。
並行稼働方針の決定：BW と新ツールを一定期間並行運用するか、ビッグバン移行にするかによって、リスクとコストが大きく異なる。データ二重管理の運用負荷も含めて計画する。