だから、私はユーザーのクラスのためのいくつかのテーブルを持つ既存のデータベースを持っています。会社が行う複数のことを処理するためのより一般的なアプリを構築しています。このクラスのユーザーは、ホストと呼ばれ、会社の複数のプログラムで使用される一般的なタイプです。現在、いくつかあるので、（最終的には）一元化されたアプリに移行したいと考えています。しかし、今は完全にそれを行う時間がありません。これらのホストのログインシステムを構築する必要があり、それを使用してこの新しいシステムへの移行を開始したいと思います。レガシーDBにあるテーブルを新しいDBに移動する合理的な方法を理解できません。新しいDBは（もちろん）別のサーバーにあり、30秒後に自分の目を刺したくありません。これに対処します。レガシーデータベースには、現在のホストテーブルへの参加に依存する多くのレポートがあります。
私が思いつくことができる唯一のことは、あまり良いアイデアのようには思えません。それらは、両方のアプリから両方のデータベースに書き込み（同期の問題が発生しやすい無意味なデータ重複）、新しいアプリからAPIを提供し、レコードセットと一緒に戻ってくるデータをマッシュアップします（ちょうど...間違っているようです）。
誰かがこれに対処する方法について何かアイデアがありますか？