Вариант 1.
Любой из уже задействованных серверов СУБД используется как место концентрации и унификации данных. Для чего настраиваются соединения (Linked Server) с иными серверами, и на этом сервере либо регулярно отрабатывает Task, который сливает данные со всех остальных серверов в некую единую унифицированную структуру, либо используется механизм распределяемых запросов (когда при обращении к View данного сервера View в свою очередь формирует запросы ко множеству иных серверов. Второй способ позволяет всегда быть уверенным в актуальности данных, но результат может получаться не только не очень оперативно, но и с очень большими задержками. Первый способ позволяет разделить по фазам сбор информации с нескольких серверов в некоторой промежуточной унифицированной структуре данных и вернуть итог запрашиваемой информации уже без обращения ко всем-всем-всем серверам. Однако, в этом случае актуальность информации может вызывать больше сомнений.

Вариант 2.
Используется сервер публикации данных и стандартные механизмы подписки, например, входящие в состав MS SQL. Преобразования к единому унифицированному формату могут происходить в процессе сбора данных на сервере публикации данных.

Вариант 3.
В качестве промежуточного места хранения данных в унифицированном формате выступает настольная СУБД (например, MS Access), либо даже таблиця MS Excel. Регулярно запускается скрипт, который задействует либо MS Query, либо ядро настольной СУБД (Jet), и в соответствующие таблицы перекачивается информация изо всех серверов. Для получения итоговых отчетов опять же задействуется либо ядро настольной СУБД, либо MS Query.

Вариант 4.
Задействуется EDI, например MS Biztalk. Это, ПМСМ, и самый грамотный, и самы "навороченный" вариант, который позволяет задействовать не только унифицированные промежуточные структуры хранения данных, но и унифицированные механизмы преобразования данных, встраивания дополнительных видов их обработки (возможно, с участием человека), отслеживания версий их структур и т.д. и т.п.