世はぺけぺけaaS全盛、どんなシステムであれ、クラウドへ持っていく検討はされているのではないかと思います。
原理的に言えば、他社とシェアするからコストも安い、運用も物理サーバはほぼ見なくて良くなるから人手も浮く（はず）。ハードウェアも動的に調達でき（ある意味ソフトウェアになる、というべきか？）、ITの機動力が高まる。
自分といえば、漠然と「オンプレやベアメタルとは共存するんだろうな」と思っていたものの、率先して「どんなシステムならクラウドでいいのか、悪いのか」の切り分ける機会がないままもうこの業界で10うん年も居たわけです。
最近クラウドへの移行やその後の運用を経験し、
「クラウドに何でも移動すればいいって訳じゃないのは分かるが、どういう根拠で、可否を考えればいいんだろう？」と思うときが増えました。
そのあたりの考察を自分用メモ。
当たり前のことを言っているように思うのですが、ご笑覧頂ければと。
結論から言うと
個人的には__非機能要件からクラウド移行の判断をする__のがベターなんだろうなあと思います。
大きい理由は、機能要件はだいたいどのaaSも満たせることが多い一方、__クラウドの場合はアプリ側で非機能要件を制御できる機構では無い__からです。
特にどんな非機能要件が勘所となるか、実体験も考慮しつつ、アプリチーム目線で考えてみました。
セキュリティ
認証は、大概の場合SSOでAD噛ませるだけでOKとして、、
（セキュリティうんぬん言ってるのだからPCでSSO出来るよね？そのクラスの会社だと思っている）
問題になるのは激烈機密情報。
__そもそもサーバをどこに置くんだ？？とか、アクセスは国内だけに絞りたい、とかの話も出てきて・・?__結局国内のプライベートクラウド（つまりオンプレ）・・？みたいな空気が漂うこともある。
グローバル展開するならGDPRとかも気になる。
ネットワーク
クラウド＝物理的な距離が離れる＝ネットワークは色々影響がでかい。
社内外の境界
ここら辺はアプリ側からすると盲点かもしれない。
昨今は特に在宅勤務が増えているので、外（インターネット）と中（いわゆる社内VPN）の間が詰まると聞く。通信帯域って、固定費高いもんね・・
ネットワーク越しのバッチ処理や、動画、音声、資料などのサイト、それに全社サイトなどのアクセス数が多いサイトは要注意。
アプリがやりとりするネットワークのデータサイズをキャパシティプランを軽く作っておいた方がいい。帯域量に応じてルーティングとかは考えてもらえるはずなので、まずはネットワークチームに相談だ！
あとセキュリティ云々で実はふさがれているIPやポートもあり、なぜか動かないとか、動くけどなんか挙動がおかしいとかもある。その場合はaaSのサポートで解決することも。
相談なしだと、・・突然全社のwebサイトがスローダウンしました！とか突然システムが使えなくなりました！ヤッホー！みたいなオチもあります。
DBやIFの複数サーバ間連携
アプリ側で解決できるタイプのネットワーク問題は、複数のDBやIFのサーバが絡み合って連携しているものを、クラウドに移動する場合。これは仮環境で調査したらすぐ問題に気がつくはず。
グローバルレベルで合理化した結果、サーバ間の物理的距離が離れてしまい、めちゃくちゃ処理が遅延する場合があるのです。
RDPは意外に低速でもストレスなく動くので気がつきにくいのでPingをおすすめ。
新環境でPingなど打つと、10倍とか20倍の値が返ってきたら要注意。
昔、DBサーバ群のうちの一つを先んじて国外のデータセンターに移動することになったのですが、I/FでDB間テーブルjoinを使っていたため、丸一日かかっても終わらんI/F処理が爆誕しかけた事例もありました。
性能要件/コスト要件
処理やIFが纏まってあるようなシステムは、クラウドに上げる場合はかなり注意が必要。
ご存じの方も多いと思いますが、想定よりも下回る性能になりがち。
VMは・・CPUとメモリだけではなく・・HDDのIOもみましょうね・・。(自戒を込めて）
RDSをクラウド化すると遅くなるパターンをよく聞くので、事前の商用データによるテストはしたほうがいいかなと。
また、I/Fがある場合、データ取り出しでもコストが掛かったりするので、併せてご注意を。
全体的に、本番環境のデータと処理を、どうにか持って行って、検証した結果を基に移行判断を行うのが良いと思います。
それが簡単に出来るのがクラウドの良いところだと思うので。
経費削減でデータを1/10しか持って行かないとかのパターンもあるんでしょうけど、それだとＶＭの各種上限まで使わないから余裕、とかもありそうなので、全部のデータは持って行った方がいいように思います。
性能要件が厳しいシステムってことは大事なシステムなんだろうし。
それくらいはコストと手間を掛けても罰当たらないと思う。
信頼性とAPI
IaaSは結構落ち着いている感じがありますが、それに引き替え、SaaSはナマモノだなぁ。
実際のところスローダウンやプチ障害は起きるし、障害が起きた場合の状況の崩れ方が汚く（処理がREST APIだったりして、結局正常に処理されたのか分からなかったりする）、データリカバリも困難なパターンが多いように思います。
あとそもそも障害を検知する為の術が極端に少ないSaaSもある。。
上記の通り、障害時の運用には厳しいものがあるので、シビアなシステムの場合、デフォルト機能で障害時に把握出来る限界を確認してみて、運用が成り立つかを考えた方がいいと思います。
出来ないなら、カスタムしてログを取得する作りにするとかを検討する。でもデフォルト以外で作ろうとすると、フルスクラッチより大変だったりすることもある・・。
また、SaaSの場合は顕著なのですが、刻々と基盤が変化していくせいか、ＸＸ技術は利用不可になりました、とか、いつの間にか機能が変更されたとか、デフォルトが変更されたとか、で動きが変わることがある。更新情報は出ているけど、全部を把握できておらず、どうしてもこういう事例は出てくる。
（プロフェッショナルなら全部把握してろよ、ってことだと思いますが、実際のところ何十も毎月出てくるし、思わぬところに影響が出るので、普通に無理です）
なので運用コストを低くしたい場合、ライセンスや使用感に問題がないのであれば、ソフトウェア変化が少なく、静かな状態を維持できるIaaSを第一選択というのがいいような気がしています。
この場合、サーバの運用管理コストは必要になってしまいます。
あと、SaaSにしたい場合、アプリチームがメンテする時間は基本オンプレよりも多くなります。
理由は、基盤がいつまで経っても枯れた技術にはならないからです。
機能が追加され、変更され続けなくなったときは、きっとその基盤は廃止対象になるときだと思うんですよ。（もしくはsalesforce方式か）
人が少ないけど、ライセンスやその他モロモロの都合でSaaSへ移行するなら、なるべくノンカスタマイズ、デフォルトのフレームワークを使う形に業務を新たに設計しましょう。
__現行と同じ、は絶対にだめ。どんなにしょぼかろうと、業務を見直すことをおすすめします。__SaaSはそれぞれ方針があり、それに応じた設計でして、絶対に、どこかにボトルネックがあるので。プロを呼んできて避けるべきです。某Notes2SPOとかその最たるもの
ここら辺の話は、以前の記事を読んで頂ければと。
バックアップ
法律要件とか機密情報とかは、たぶんデータバックアップをとることになる。
SaaSは断面をとるのは難しい。（出来ないとは言わない）IaaSは簡単。
運用面を考えると、シビアなシステムはIaaSを押します。
とはいえIaaSでも、時間不定で走るバックアップで一瞬寸断したりして困るけど、これはクラウドによるのかな。。
他に何か勘所あるかしら。良い案があったらむしろ教えてください。