E o que tem tudo isso a ver com a migração.
Então.... voltando à migração.
O aplicativo roda perfeito?
Ótimo, não tem pressa SQL.
Como fazer migração aos poucos?
Escolha uma tabela de cobaia, de preferência das tabelas menores e com pouco uso.
Crie a tabela equivalente no SQL.
Altere a exclusão, pra além de apagar no DBF também apagar no SQL.
Pode até deixar em uso, sem problemas.
Altere a parte de alteração, pra gravar no DBF e também no SQL.
Pode até deixar em uso, sem problemas.
Altere a inclusão, pra gravar no DBF e também no SQL.
Pode até deixar em uso, sem problemas.
Aqui pode gravar todo o cadastro do DBF no SQL.
E pode deixar em uso, sem problemas.
Vá acompanhando se tudo ok, se tudo está gravado nos dois.
Altere o cadastro, passar a usar o SQL como principal, e o DBF como uma espécie de backup.
Vá alterando listagens, e outros lugares, pra ao invés de usar o DBF, passar a usar o SQL.
Se tudo ok, só eliminar o uso do DBF dessa tabela.
É diferente conforme a tabela/arquivo.
Vai chegar num ponto, onde vai preferir mudar tudo de uma vez pra SQL, porque vai perceber que tudo fica mais fácil se tudo estiver no SQL.
Principalmente nas listagens.
Com gravação em DBF e SQL ao mesmo tempo, pode verificar se tem alguma coisa falhando, se esqueceu de alterar alguma coisa em alguma rotina.
A qualquer momento pode refazer a gravação no SQL partindo do DBF.
Então, é começar a fazer, e conforme for pegando confiança e se acostumando, você mesmo vai escolher o próximo passo de sua conversão.
Vai depender muito do seu estilo de programação, de repente pode escolher dar uma geral nos fontes antes de prosseguir, no começo ou no meio da conversão.
Gravar nos dois NÃO vai deixar mais lento, exceto aonde faz muitas gravações de uma vez.
No SQL fica mais rápido gravar 1.000 registros de uma vez, do que gravar um por um.
Parece a mesma coisa, mas não é, vai descobrir isso.