はじめに

この記事は『[SAP on Azure] これからはじめるAzure環境構築とSAPシステム移行 - Azureを使いはじめる前に -』の続編として投稿しています。移行について記載しますので、Microsoftのドキュメント「SAP NetWeaver のための Azure Virtual Machines の計画と実装」を読了していることや、VNETやVMといった環境構築が可能な状態になっていることが前提です。「あれ？これってなんだっけ？」と引っかかるものがあれば、前回のブログ記事やドキュメントをご確認ください。前回同様にゆる～く書いています。

この記事で書かれていること

この記事ではSAPシステムのAzure移行ついて記載します。前回の記事の「データ移行をどのように実施するか？」で触れていますが、開発・検証機を含めた全システムの「ダウンタイム」「移行時期」「移行手順」や、（触れていないですが）そういった情報が集約された「移行方針」の検討を深堀してみます。
環境については、Windows / SQLServerで構成されたSAPシステムと、周辺の運用管理・帳票・アーカイブがあることを前提とします。わりと現実味があるかなぁと思っています。

この記事に書かれているタスクが実施されるのは、移行PJ開始直後をイメージしています。内容は具体的な移行手順の話よりも方法論に寄っていますのでご承知ください。というものの、メインどころの移行にまつわる話でWindows / SQLServerについて記載していますので、やはりSAP on Azureという軸なのです。

対象読者

そろそろH/WやOS/DBの保守が切れるんだけど、まだS/4HANA化まで手をつけられないから目の前の物理機器だけでも更新と思う、SAPベーシスな方々を想定しています。だいぶ絞っていますが結構需要があるのでは？

移行のモヤモヤを移行方針に落とす

手ぶらでいきなり魔法のように移行できるなんてことはありません。どんなシステムでもそうですが、移行のもやもやした考え事をとりまとめ移行方針とすることで、クラウドの設計やテストのゴールとすることができます。移行方針を作るまでの道のりを辿ってみるのがこの記事のおはなしです。

製品情報のまとめ

まず、現在使用している製品（OS/DB/業務アプリケーション）のバージョン・パッチレベルを含めた情報を収集します。普通は導入時に一覧化されていますが、その後システムは更新したもののドキュメント更新されていない、といったことも有り得ます。また、SAPシステムについてはERPやCRMといったアプリケーション部分は管理していてもNetWeaverバージョン・SPSレベルやSAP Kernelのパッチレベルが管理されていないこともあります。地道なチェックと一覧化を実施します。このとき、例えば帳票やアーカイブといった周辺システムにはJavaやTomcatなどのミドルウェアが含まれていることがあるので、その辺漏れないように。基幹システムの保守をしていると長期的に製品バージョンが変わらないので忘れがちですが、Javaと聞いた瞬間に「もしやOracle Java？ライセンス！」と反応するためにも日々の情報インプットを怠らないようにします。特にSAPベーシスの方は通勤時間のうち10分程度のIT絡みのTweetチェックは画面スライドするだけという簡単作業ですのでオススメです。

移行先のOS/DBバージョンを暫定決定

H/W移行を実施する際、大抵はOSやDBのサポート期限も間近に迫っています。iPhoneを新しく購入したときにわざわざ古いiOSを入れないのと同じで、"通常の場合は"OS/DB両方とも最新バージョンにバージョンアップします。また、古いiOSだとポケモンGoなどのアプリが対応しなくなるように、業務アプリケーションも古いOS/DBには対応・サポートしなくなるので、業務アプリケーションを新しいOS/DBに対応させる必要があります。この際、業務アプリケーションに対してはパッチ適用や、場合によってはバージョンアップする必要があります。
"通常でない場合"は最新バージョンではなく、その少し手前のOS/DBバージョンに移行します。その先のS/4HANA化PJを見据えており、最新OS/DBとせずとも一つ前のバージョンでS/4HANA化PJ完了までのサポート期限（望ましいのはメインストリームサポート期間）を満たしている場合です。これは後ほど出てきますが、ダウンタイム・移行にかけられる予算と絡めた結果導き出される結果です。今この段階ではこういった話まで踏み込めませんので、いったん脇に置いておきます（後ほど再登場します）。

対応する業務アプリケーションのバージョン・パッチレベルを確認

H/W移行に伴ってOS/DBを変更する際には、いままで使っている業務アプリケーションがそのまま使えるのではなく、基本的にパッチ適用なりバージョンアップなりが発生すると考えましょう。
先に出てきた通常通りのパターンと通常どおりでないパターンのいずれの場合も検討することとします。先に現在のシステムをバージョン・パッチレベル含めて一覧化しているので肉付けしていきましょう。
SAP製品の場合は毎度おなじみPAMを使ってそれぞれのパターンのOS/DBバージョンに対応するNetWeaverのSPSレベルやSAP Kernelのパッチレベルを確認します。周辺システムは各ベンダーのサポートページ等に記載されていますので、こちらもそれぞれ確認していきます。このときJava/Tomcatなどのミドルウェアとの対応関係も忘れず確認しましょう。製品は対応しているように記載しているけどミドルウェアがダメでしたという場面に出くわすこともあります。特にJavaはOracle Java以外にもOracle OpenJDK・Amazon Corretto・AdoptOpenJDK・SapMachineなど複数あり、製品ごとに対応しているJDKが複数あったりしてそれぞれ調査することとなります。

バージョン変更による製品仕様・挙動の差異は何か

ここまでの作業で現状と移行後の情報が一覧にまとまります。ほぼ全ての製品がパッチ適用・バージョンアップの対象になってくると思います。
さて、それぞれの製品をバージョンアップすると何が変わるのでしょうか？？？全く分かりませんよね。なので、現行バージョンと移行後のバージョンの差異による変更点を見ていく必要があります。ただ微妙に変わるだけなら良いのですが、運用に関わる機能が変更されていたり、メモリ消費量が変わっていたり、見えないところにも変化点が出てきます。ここは普段あまり読むことのないリリースノートを最大限活用して変更点をまとめておきましょう。
まとめた後の変更点確認ですが、業務アプリケーションについてはSAPベーシスチームのみの作業ではなくアプリケーション保守チームを巻き込みます。ベーシスチームでは把握していない機能の変更点が見つかることが多く、時にはクリティカルな内容であったりして、皆を驚かせます。

業務ユーザー側のアプリケーション担当者と会話する

さて、ベーシスチーム・アプリケーション保守チームの確認が終わり、一覧にはいつの間にか変更の影響範囲まで記載されています。そろそろ影響確認も終わってきましたので「だいたいこんな感じの変更があって、こんな影響が見えています」と業務ユーザー側の担当者と会話しましょう。「えー！変わるの嫌だ！」と言われても、「行く川のながれは絶えずして、しかも本の水にあらず。よどみに浮ぶうたかたは、かつ消えかつ結びて久しくとゞまることなし。」と方丈記に書かれているように変わらないものは無いし、逆に変わらないものは気持ち悪いでしょう。変化を受け入れ適応していく柔軟性が必要です。変わってしまうものは変わってしまうので、どのように受け入れてどのように対応していくのか、Goliveまで時間のあるこのあたりのタイミングで議論を始めるべきです。

ベーシスから見た本当の移行対象は何か？

業務側の変更点議論が始まっている裏で、ベーシスな人々はOS上の何を移行するのか検討を始めます。OS/DB/業務アプリケーションでざっくりとレイヤーを区切り、果たしてどんなファイル・どんな設定内容を移行すべきか検討します。ぶっちゃけた話、移行先で直接設定したほうが早いものもありますので、見極めていく必要があります。
というわけで、このタスクで移行データサイズや移行先環境に予め設定しておくべきものが判明します。

OS

Windows上で持っているものといえば、各種ファイル・アカウント情報・手作りしてしまった権限といったものがあります。それぞれ見ていきます。

DB以外のファイル/フォルダ

DBはこの後出てきますので、それ以外でどんなファイルが必要なのか洗い出していきます。J-SOX監査対象システムであれば、OSレイヤーでのWindowsイベントビューアで確認できるセキュリティログや業務アプリケーションレイヤーでの監査ログが必要となってきます。後者はSAPシステムでいうところのTrCD:SM20の裏にあるAuditファイルですね。他には業務アプリケーションがシステム間連携のためにファイルを出力していたりします。SAPシステムといえども、全てがDB上に保管されているわけではありません。他にも移送関連ファイル・システムのプロファイルパラメータなどは物理ファイルの移行がキモとなります。この、全てがDB上に保管されているわけではないという考えは周辺システムにも同じことが言えますのでしっかりと確認しましょう。
フォルダ構成についても現在のシステムの各フォルダ階層を移行前に確認しておきましょう。フォルダを確認する際に、親フォルダから見たフォルダサイズをチェックしましょう。子フォルダまで見ていくとキリがありません。
ファイル/フォルダの権限をうまく引き継ぐため、移行時にはrobocopyを使うようにします。xcopyだと256文字のパス制限に引っかかったりするので辛いです。

アカウント/権限

Windowsのアカウント情報や権限は移行時に意外と抜けがちな部分でもあります。現在のシステム登録されているアカウント・そのパスワード、また権限（特に作ってしまったものの有無）、といった部分を確認しておきます。
パスワードが分からなかったら諦めて本移行時に関連する箇所のパスワードを頑張って変更しましょう。絶対ミスが出るので、ぶっつけ本番ではなく移行リハーサルで変更・テストまで確認します。

DB

SQLServerの移行は少し確認事項が多いですが、割と簡単です。

ユーザーDBファイル

SQLServerのユーザーDBは移行対象です。単純なデタッチ/アタッチやバックアップの利用で移行できます（もちろん互換の範囲はあります）ので、特に気にすることはありません。デタッチ/アタッチであればmdf/ndf/ldf各ファイルを移行し、バックアップファイルの利用であれば例のbakファイルを使います。デタッチ/アタッチのほうが良いのか、バックアップファイルのほうが良いのかは、手順に沿って移行時間を実測してから決めることです。

アカウント/権限など

一般的にSQLServer移行で厄介なのは、ユーザーDBではないところに保管されている情報です。システムDBに含まれるアカウント情報や、Windowsレジストリの値、ローカルセキュリティポリシー（メモリ内のページロック設定やSAPServiceSIDのユーザー個別設定）など。
まずシステムDBについてはSP/CUレベルまで合っていないとデタッチ・アタッチやバックアップファイルでの移行ができないので無理筋です。レジストリの値なんかもレジストリファイルを持っていったらOS破損しそうですね、これもやめておきましょう。
これらの移行はデータベースを別のサーバーで使用できるようにするときのメタデータの管理を参照して頑張ります。例えば現行システムのSQLServer初期インストールパラメータが分からないといった事態が発生した場合、「C:\Program Files\Microsoft SQL Server<バージョン>\Setup Bootstrap\Log<インストール日時>\」配下にファイル「ConfigurationFile.ini」が存在するのでそちらを確認する、といった行為に走れます。このファイルは下図のようになっており、（例として扱いやすいので使いますが）Collationは"SQL_Latin1_General_CP850_BIN2"になっている、といったことが確認できます。画像はSQLServer 2017 Developer Editionインストール時のものです。

ところで、SAPシステムのDBとしてのSQLServerであればインストール時およびSolution Manager接続用に作成されるアカウントのみが存在し、他のアカウントが登録されることはほぼありません。これはSQLServerライセンスをSAP社経由で購入しているか、それとも自社で別途Microsoft社パートナーから購入しているかによって違いが出てきますが、ライセンスをSAP社経由で購入している場合はまず発生しないでしょう。
少し脱線しますが、通常SAPシステムのSQLServerにわざわざ追加アカウントを作る場合、他システムとのDB直接接続が目的となります。DB管理者であってもABAPスタックの場合はWindows認証、Javaスタックの場合はMix認証で予め準備されているアカウントでログインします。で、SAP社経由でライセンス供与を受けている場合はランタイムライセンスであり、SAPシステムを経由せずにSQLServerに直接ログインして別のアプリケーションにデータ連携するといった使い方はライセンス条項に抵触しています。このため「まず発生しないでしょう」と記載したわけです。もしも見かけないアカウントがあれば利用用途を確認してみましょう（地雷でないことを祈るのも忘れずに）。

業務アプリケーション

業務アプリケーションについてはあまり考えることはありません。データはDBが持っているからです。ただ、DBを持っていない業務アプリケーションについては、移行先のシステムに頑張って直接設定しなければならないことがあります。

固有の設定情報（ファイル/DBコピーしても引き継がれないもの）

周辺システムでは移行ツールを使わないと内部の設定情報が引き継がれないけれども移行ツールに費用を払いたくない、といった状況に陥ることがあります。そういった場合は個々の設定を実施することとなります。
また、運用管理ツールでは、ジョブ等の定義Export/Importの必要性はありがちで、しかもExportとImportの間に手作業が入る場合があります（モヤモヤした苦い想い出があります）。
何も考えずに移行することはないと思いますが、各業務アプリケーションには移行ガイドが存在すると思いますので、それらをよく読み解くようにしましょう。1回読んだだけで理解したとは思わず、1回目の最後の方に出てきた内容が頭に残っているうちにもう一周読み込むと、重要な情報がコッソリと書いてあるといった発見があったりします。

ダウンタイム・移行手順の検討

ここまでで移行の概要はある程度固まってきています。続いて、概ねPJ開始前に決まってしまっているダウンタイムに対し、果たして移行手順がそれを満たせるのか確認していく必要があります。このタスクを早めに実施することで、本当にどう足掻いてもダウンタイムを満たせない状況が出てきたときに「ダウンタイムもうちょっと頂戴」と業務側メンバーと協議する際の材料となります。移行PJのような地上戦に対して、試してもないものを元に空中戦を展開するのは好ましくありません。というか仕掛けようとしても「実際どのくらいかかるんですか？」と一撃ノックアウトです。地上戦展開のためには、ゴールへのルートを複数準備するための期間も必要です。
また、早めにダウンタイムを確認・検討することで、ビジネスパートナーを含めた連携システム管理者に対し、比較的長いリードタイムを提供することも可能です。相手側の調整期間の配慮ができる真っ当な人間でありたいものです。
このような理由から、移行PJの早い段階で移行手順と実際のダウンタイムの確認が必要となります。

なぜダウンタイムを考えるのか

ダウンタイム＝ビジネスインパクトだからです。自社の活動のみで済めばよいですが、長大なサプライチェーンの中ではビジネスパートナーの活動にも影響を及ぼしかねません。従ってダウンタイムを検討する場合にはビジネスパートナーとの連携や、自社の活動時間が考慮されている場合がほとんどです。これを動かすための調整は難航することが予想されます。

移行手順に基づくダウンタイムの確認

ベーシス担当者であれば、移行手順を複数検討することは当然と思います。ある手順がダメでも他の手順であればゴールへ辿り着ける、という場合がよくあるからです。どの移行手順を踏むのか確認できるタイミングは先の通りPJ開始後の早い段階しかありません。ここで複数の手順を検討・確認して本移行の手順を確立してしまい、その全体作業時間からダウンタイムを導出します。
ダウンタイムの中で大きなウェイトを占めるのはSQLServerユーザーDBの移行です。デタッチ/アタッチのようなオフライン移行を実施するのか、それとも事前にバックアップ・リストア形式で移行しておき差分をログ配布してNear Zero Downtimeとするのか、あるいはもっと別のソリューションを検討するのか、このあたりの手順を確認・実測してダウンタイムを導出します。SQLServerはログバックアップをリストアする際も上位のバージョンで可能ですので、周辺システムによってはNear Zero Downtimeで移行することも可能かもしれません。SAPシステムではNetWeaver SPSの適用が必要ですのでテーブル構造が変更されていることを考慮しオフライン移行が堅実です。周辺システムについてもそれぞれの製品ごとに確認しましょう。
どうしてもダウンタイムが短くならないのであれば、ターゲットとなるWindows / SQLServerのバージョンが少し前のバージョンでもOKの場合に限り、SAPシステムのNetWeaverに適用するSPSの数が少なく済むのでダウンタイムを短縮できます。ここまで手順確認してきたベーシス担当者にとっては自明のことですが、今回の構成であればSAPシステムの移行（データ移行とSPS適用）がクリティカルパス上に乗ってきます。もしも暫定OS/DBバージョンではダウンタイムに収まらない場合、この案も含めて最終的なOS/DBのターゲットバージョンを確定しましょう。どうしてもOS/DBに引き摺られて業務アプリケーションのバージョンが変わってしまった場合、業務側メンバーと会話していた変更点やシステム運用機能の変更点についても再度チェックする必要があります。
ようやくOS/DBのバージョンが固まり、併せて業務アプリケーションの対応バージョンが固まってきます。

移行手順はExpressRouteの帯域幅にも影響します。大きなデータだけれどもオフライン移行しかない、という場合にはExpressRouteの帯域増速を検討します。どの帯域で契約するのか移行対象データをもとにした計算も必要です。ExpressRoute帯域の対応のみでどうにもならない場合は、Premium SSD Managed Disksのストレージ構成検討が始まります。

移行手順に基づくダウンタイムを導出したら、資料にまとめて業務側メンバーと会話しましょう。このときに、PJ開始前に決まってしまっていたダウンタイムよりも短ければしゃんしゃん、ダウンタイムが長くなるようであれば受け入れてもらい関係各所との調整準備を開始してもらいましょう。あるいは、折り合いがつかなければ予算を追加して必殺SNP社のT-Boneが登場するのか。何度も言うようですが、このあたりの会話は早ければ早いほど良いです。

移行時期の検討

本番システムの移行日はPJ前に決まっているとして、開発・検証システムの移行時期をPJの中で検討します。本番システム移行日に開発・検証システムの移行を併せて実施することは望ましくありません。移行日に開発・検証システムのみを移行するようなメンバーを採用するとしても、そのメンバーに対してPJメインメンバーが引継ぐ工数の増加や、移行日に面倒を見なければならないという無駄な雑務の増加が見込まれます。じゃあ最初からそのメンバーをPJに入れておくかと言われると、そこまで工数・費用をかけるものか？という疑念を拭えません。そのため、開発・検証システムはPJメンバーが本番システム移行日とは別の日に実施することとします。

検討ポイントは何か？

本番システムの移行日までは、現在のシステムが稼働しています。
移行先の環境ではOS/DB/業務アプリケーションのバージョンが変わるため、開発・検証システムの移行タイミングが早ければ早いほど現在のシステムの保守との絡みでダブルメンテナンスの発生量が多くなります。このダブルメンテナンスを業務アプリケーション保守担当者がどこまで受け入れられるか、が検討ポイントです。従ってベーシスや業務側メンバーの一存で適当にスケジュールを決めると怒られます。業務アプリケーション保守担当者と落としどころを話し合いましょう。

移行方針を確定する

各システムの移行時期・移行手順・ダウンタイムの確認や調整が固まってきましたので、改めてPJ全体の移行方針を策定しましょう。方針には、このあと揺らぐと困ることを記載するのが基本です。

どこまで書くか

ここまでくると、各システムのもう少し細かな部分まで触れたくなるかもしれませんが、あくまでも方針レベルですのでもっと細かな部分は各設計書に落とし込めばよいです。
ちなみに、「移行方針はどこまで書けば良いのか？」「なにかサンプル無いのか？」という方は、「特許庁における業務・システム最適化」に係るシステム開発関連情報の公表に公表されている移行方針書が参考になります。これすごいですよ。細かく記載されているので「我々はこのあたりまで記載されていれば良いな」と項目取捨選択のベースにすることもできます。ありがたや。
ここでは、簡単に3つの事項を記載しますが、個々のタスクは意外と重いです。。。

前提条件

前提条件はそれなりに記載事項が多いはずです。
本記事の内容であれば最初に「オンプレミスのSAPシステムおよび周辺システム（運用管理・帳票・アーカイブ）をAzureに移行します」といったスコープや移行先の宣言があり、そこからOS/DB/業務アプリケーションや非機能系のソフトウェア・基盤サービスといったものを含めた移行前後の対比表なんかあると良いかもしれません。また、既に調整の始まっている本番移行当日のダウンタイムや体制といった情報を組み込んでいきます。

移行スケジュール

移行後のサポート期間までの大日程を作ります（WBSレベルからボトムアップで作りますが、逆から日程を引くと破綻します）。本番環境移行や開発・検証環境移行、リハーサル、各種テストなどは当然ですが、運用への影響を確認するタスクも忘れず組み込みます。

移行イメージ図

ここまでに確認した各システムの移行手順の概要イメージを絵に落とします。
ここで移行イメージ図を作っておけば、後々に発生する諸々の説明時にかなり役立ちます。例えば業務側メンバーやシステムオーナーといった技術的に明るくない方々に移行手順を読めというのはいささか横暴ですが、PJメンバーである以上はどういったことを実施するのか概要を理解してもらう必要があります。何か不具合が発生した場合にどこで何が発生したのか理解してもらうときや、チーム間の共通言語を作り出して距離を縮めることの一助ともなります。

おわりに

そんなあっさり終わるなと言われそうですが、今回の話は移行方針を決めることでした。
そのためにはダウンタイム・移行手順・移行時期といったものを確認していく地道なタスクが必要となり、移行PJの半ばに開始しているようでは到底間に合わないような内容です。技術的には簡単なのですが、調整ごとや考えごとが多いのが既に本稼働しているシステムの移行です。
この記事が対象読者の方の一助となれば幸いです。

それでは！