Integração entre Sistema em ambientes diferentes

Complementando,
Minha proposta inicial para o problema, é solicitar as desenvolvedores do sistema legado, que registrem as mudanças em clientes em arquivos TXT, estando estes arquivos em um pasta compartilhada de rede, e assim, eu irei instalar no ambiente do cliente, um aplicativo java desktop, que vai ficar monitorando esta pasta compartilhada e assim que um arquivo txt ali for depositado, este aplicativo java vai fazer a leitura e vai transmitir via web-service para a minha aplicação no Data Center externo.
Fico a espera de outras sugestões …

Que tal colocar triggers nas tabelas do sistema legado, fazendo uma cópia dessas alterações para o seu sistema ou para alguma outra tabela?

clone_zealot,
Eu não posso fornecer o acesso do BD do meu sistema que está em um DataCenter para o sistema legado que está em outro ambiente, questões de segurança.

O cadastro de clientes fica na máquina local, e não no servidor?
Dependendo do banco tu podes setar ele como servidor, e fazer a tua aplicação WEB conectar-se a ele.

Pra ser breve e objetivo como vc foi e não ficar elencando aqui as diversas vantagens e pontos de antenção que vc bem deve conhecer, e se não conhecer a gente pode conversar depois, vou dizer o que, certamente, dá pra ser dito. A modelagem conceitual da sua solução está condizente com os requisitos e restrições que vc menciona e a implementação não tem segredos.

Spranta,
Primeiro identifique quais são os pontos falhos no seu modelo para integração, exemplo.

Se você pretende criar uma integração em tempo real e no sistema existe um trafego considerável de informação podem ocorrer situações com problema em escrita nos arquivos nas seguintes situações:

-Duas instâncias de dois processos compartilham um mesmo arquivo txt e tentam solciitar a escrita ao mesmo tempo.
-Duas instâncias de um mesmo processo tentam escrever no arquivo txt ao mesmo tempo.
-Queda do sistema legado durante escrita em arquivo txt além de corromper o arquivo podem defasar as duas bases.
-Tempo de sincronização é alto e sem controles.
-Arquivo não poderá ser lido antes de sem completamente escrito.
-Espaço em disco, será acumulado um volume de arquivos em disco.

Com essas situações você poderá ver os pontos falhos na sua solução e quais são os possíveis contornos, por exemplo para o arquivo não ser lido antes de recebido uma movimentação completa você poderá usar arquivos indicadores, sendo um arquivo de dados e um indicador que dispara o processo e é gravado após o termino do arquivo de dados.

Quanto a outras possíveis soluções, uma que seria interessante é uma solução baseada em filas persistentes como JMS, AQ ou MQ-Series, caso não fosse possível, você pode arriscar com Sockets usando suporte no conceito de caixa d’agua para evitar as perdas de movimentação.

Por acaso não seria possível que o seu próprio Client em Java que vai rodar na plataforma cliente identifique as movimentações e as transmita via WS?