Você menciona que a conexão leva muito tempo - depois que a conexão é estabelecida, as operações / consultas prosseguem em velocidade normal? Se for apenas estabelecer conexões lentas, mas você puder receber conjuntos de resultados em uma taxa normal, eu me certificaria de que não há problemas de autenticação, pois o site não está adequadamente definido para o servidor de banco de dados e está consultando um DC em um local remoto ou não está usando um servidor DNS apropriado.
Se as operações forem lentas após você ter estabelecido a conexão, será necessário iniciar a solução de problemas do motivo pelo qual o novo servidor está em execução.
Antes que você possa dizer que o servidor A é melhor que o servidor B, ou equivalente, ou pior - você realmente precisa ter uma linha de base.
Por exemplo - para todos os meus servidores de banco de dados, eu executo um conjunto de IO SQL ( link ) benchmarks para várias permutações de leitura / gravação. Então, antes mesmo de instalar o SQL Server ou qualquer outra coisa, vejo como a nova plataforma se compara ao que eu estava trabalhando antes. Mantenha uma história.
O mesmo com o desempenho da rede - você pode usar algo como o iperf para medir a largura de banda bruta entre as máquinas na mesma sub-rede, diferentes sub-redes, diferentes sistemas operacionais
Eu começaria com testes básicos como esse para ver se algo aparece. Só porque o novo servidor parece mais poderoso no papel não significa que realmente é. Se isso parecer bom, inicie o benchmarking de operações reais no SQL Server.
As VMs podem ser facilmente restringidas por outra carga em seus hosts. Talvez o servidor de banco de dados tenha seu armazenamento em um agregado de armazenamento que é superutilizado ou CPUs superutilizadas.
Veja se as estatísticas não processadas parecem boas, então veja se é algo específico para o caso de configuração do produto (sql server neste).