こんにちはです。

弊社では、システムごとにSQLサーバーのライセンスを購入しており、「これって無駄じゃない？」と言われています。
確かにこれは別の意味で無駄かと思います。
例えばSQLServer2005が導入されているシステムが３つ存在し、100人でそのシステムを利用する場合などは、100×3=300CALではなく、ユーザCAL又はデバイスCALを100購入すれば問題無いと思います。
ユーザCALは社員に、デバイスCALは端末に付与するイメージですので、SQLServer2005のシステムが追加になっても
接続する数量が変化しない場合は、CALを購入する必要はありません。
但し40CALぐらいを超えるとCPUライセンス（接続無制限）の方が安くなってくるので、接続人数又はデバイス数で異なります。
あとライセンスは下位互換ですので、SQLServer2005ライセンスで上位バージョンのSQLServer2008の接続は出来ません。
現在販売中のCALはSQLServer2008R2で、これが一番の上位となります。
よってSQLServer2008R2のCALを購入すると下位のSQLServer2008・SQLServer2005も接続可能となります。
SQLServerライセンス形態もWindowsServerと大体同じようです。
＃的外れでしたら、ご容赦を・・・

アプリケーションの開発や保守をしていた側からのコメントです。
参考程度に読んでください。

想像ですが、以下のような点を注意すればいいのではないでしょうか。
【サーバとアプリケーション】
・サーバＯＳに対する独自設定の有無(相反する設定がないか)
・ＣＰＵ、メモリの通常時とピーク時の使用量
※ハードウェアが分散されていたのを１台または数台にするのでＣＰＵやメモリの増設が必要になる可能性がないか確認するため。
【ネットワーク】
・ネットワークに掛かる通常時とピーク時の負荷(サーバ別に必要な場合はサーバ別に調査)
※ハードウェアが分散されていたのを１台または数台にするためネットワークアクセスが集中するので、ネットワーク機器の増設やネットワーク仮想化が必要となるケースが想定されるため。
※展示会に行った時、サーバ仮想化製品より出店数は少なかったですが、ネットワーク仮想化の製品も数社出店してました。

他に作業とは別で、以下の点について注意が必要かと思います。
【保守契約】
・利用されなくなったサーバ機器の保守について
　　一般的に１年更新のため、契約途中で解約した場合でも保守料が返却され
　　ない可能性があります。
・利用中のアプリケーションについて
　　市販されているアプリケーションの場合、問題はないのですが、
　　オーダーメイドまたはカスタマイズを自社独自で入れているアプリ
　　ケーション場合、アプリケーション開発元との保守・サポート契約が
　　無効になる可能性があります。
　　※対策としては、統合作業にコンサルタントとして入ってもらう方法
　　　がいいのではないかと思います。費用は発生してしまいますが、
　　　継続して保守・サポートを受けることができると思います。

10年ほど前ですが、お客さん先でＤＢサーバの統合プロジェクトをやっていました(私自身は別プロジェクトでしたが)。実運用に入って月末月初のレスポンス(反応速度)が悪くて、大変な状況になったのを覚えています。今と違って、ギガビット・イーサネットやネットワーク仮想化の製品もない頃だったので・・・最終的にはサーバを増設して対応したと記憶しています。

こんにちは

皆さんの回答に付け加えて、補足的にコメントします。

①ネットワーク集中することによる負荷の高まりがあるのと同様に
　ディスクへのＩＯ集中による負荷も意識しないといけないと思います。
　ディスクそのものの負荷もそうですが、コントローラー性能も
　少し意識したほうが好ましいです。（勉強にもなると思います）

②同じ筐体のハードに入れた場合、今まで別々の筐体で
　動いていたけどひとつで動くことになるので、故障があった際には
　何もしないで標準的な構成だと全システム一斉に止まる可能性が
　あります。
　重要度にもよりますが、あらゆる部分で二重化などの措置をするか、
　そういう構成のハードを導入したほうがいいと思います。
　一般的なハードメーカー以外にもこういうハードもあります。
　（値段は確か高いですがその分安全性は高かったはずです・・・）
　http://www.stratus.co.jp/technology/index.html

特にＤＢについて言いますと

③そもそもどのような構成でサーバーを立てるのかを考えたほうがいいと
　思います。

　ずいぶん触ってないのでうる覚えですが、ＳＱＬｓｅｒｖｅｒの場合
　インスタンス　→　サーバー　→　データベース　→　テーブル
　の順で作成され、
　インスタンス＝物理サーバーだったような気がします。

　元々の構成は
　複数物理サーバー＝複数インスタンス→サーバー名→ＤＢ名→テーブル名
　になっていると思いますが、統合する場合、

　ひとつの物理サーバーにインスタンス、ＳＱＬサーバーをひとつづ作り
　その中に複数のＤＢを作るのか・・・・
　（とにかく一個のＳＱＬサーバーにまとめてしまう）

　それとも、物理サーバーひとつに対し、複数のＳＱＬサーバーを作り
　その中にそれぞれ移行するのか・・・・・
　（元々存在した物理サーバーの数だけ、ＳＱＬサーバーが論理的に存在）

　前者はアプリケーション修正の可能性が高まります。

　後者はうまくやればアプリ修正なく出来そうな気がします。
　※ＩＰ変更かかる場合は名前解決でうまくやる必要があります。

このあたりを気にしたほうがいいのではないかと思います。
ＶＭ使う場合には全く違いますが・・・・

私もあまり詳しくないので、実際には詳しい方に聞いていただくか
してくださいませ。

こんな感じで検討の思考を広げてみてはいかがでしょうか？