Como migrar um sistema desktop para a web

O sistema foi escrito em Delphi, VB6 ou Access há muitos anos, roda instalado em cada máquina e conversa direto com um banco no servidor da sala dos fundos. Ele funciona. O problema é tudo em volta: acesso remoto improvisado, instalação que quebra a cada atualização do Windows, filial que precisa de VPN para lançar um pedido e um desenvolvedor original que já não está por perto.

Levar esse sistema para a web é uma decisão sensata na maioria dos casos. O que costuma dar errado não é a tecnologia nova, é subestimar o que o sistema antigo faz sem que ninguém perceba. Este texto trata do como: onde as regras se escondem, como conviver com as duas versões, o que fazer com impressoras e balanças e como não destruir a produtividade de quem usa a tela há anos.

O que o desktop faz e ninguém lembra

Peça para a equipe listar o que o sistema faz e você vai receber uma lista de telas: cadastro de clientes, pedidos, faturamento, relatórios. Essa lista está sempre incompleta, porque o que mais importa não aparece como tela.

Alguns exemplos típicos do que fica de fora:

• Validações silenciosas. O campo de desconto que não aceita valor acima de certo limite para determinado perfil, sem mensagem nenhuma.
• Rotinas que rodam ao abrir ou fechar. O sistema que, ao ser aberto pela primeira vez no dia, recalcula vencimentos ou gera arquivos para o banco.
• Efeitos colaterais de um botão. Gravar o pedido também atualiza o limite de crédito, gera uma pendência no financeiro e envia um arquivo para uma pasta compartilhada que outro sistema lê.
• Arquivos locais. Configurações em arquivos INI, relatórios que dependem de uma impressora padrão, exportações salvas numa pasta de rede com nome fixo.
• Relatórios que viraram processo. Um relatório impresso toda segunda-feira que, na prática, é a lista de trabalho de um setor inteiro.

A primeira etapa de uma migração séria é observar o uso real, não ler o manual. Sentar ao lado de quem opera, registrar os caminhos que a pessoa faz, perguntar o que acontece depois de cada clique. Se o sistema chegou até você sem documentação, o roteiro de como assumir um sistema legado sem documentação é o ponto de partida.

Onde estão as regras: telas, procedures e gatilhos

Em sistemas cliente-servidor, a regra de negócio raramente mora num lugar só. Ela costuma estar espalhada em três camadas:

No código das telas. Em Delphi e VB6 é comum a regra estar no evento do botão ou na saída de um campo: calcular imposto, validar CPF, decidir o próximo status. Ler esse código é trabalho braçal, mas é onde estão as decisões mais antigas.

Em stored procedures. Muitos sistemas dessa geração colocaram a lógica pesada no banco, em procedures de SQL Server, Firebird ou Oracle. Isso é uma boa notícia: a regra está num lugar consultável e pode ser reaproveitada durante a transição.

Em gatilhos (triggers). O caso mais traiçoeiro. Um gatilho que atualiza o saldo quando um item é inserido, ou que grava um histórico a cada alteração, age sem que a aplicação saiba. Se o sistema novo gravar no mesmo banco, o gatilho continua agindo; se gravar em outro, a regra simplesmente desaparece.

O produto desta etapa é um inventário de regras, cada uma com origem (tela, procedure, gatilho), descrição em linguagem de negócio e um exemplo concreto de entrada e saída. Esse inventário vira a base dos testes que vão provar que o sistema novo se comporta como o antigo onde precisa, e de forma diferente só onde a empresa decidiu mudar.

A pergunta sobre reaproveitar ou reconstruir cada parte é a mesma discutida em reescrever ou refatorar um sistema legado: no cenário desktop, a interface quase sempre é reconstruída, mas a lógica no banco muitas vezes pode ser mantida por um tempo.

Banco compartilhado como ponte durante a transição

A decisão de arquitetura mais importante é como as duas versões vão conviver. Existem dois desenhos principais.

Banco compartilhado. O sistema web lê e grava no mesmo banco que o desktop usa. É o caminho que permite migrar por módulo sem sincronização: o pedido lançado na web aparece imediatamente no desktop, e vice-versa. O custo é aceitar temporariamente um modelo de dados antigo, às vezes mal normalizado, e respeitar os gatilhos e procedures existentes.

Banco novo com sincronização. O sistema web nasce com um modelo limpo, e uma camada de integração mantém os dois bancos coerentes. Dá mais liberdade, mas introduz tudo o que integração traz: atraso, conflito, reprocessamento e a pergunta de quem é dono de cada dado.

Na maioria das migrações de desktop, o banco compartilhado é a ponte mais segura, com uma disciplina clara:

• O sistema web acessa o banco antigo por uma camada de acesso isolada, para que a troca do modelo de dados no futuro não exija reescrever tudo.
• Tabelas novas, criadas para funcionalidades que só existem na web, ficam num esquema separado.
• Cada gatilho e procedure relevante é documentado e testado antes de o módulo web entrar em produção.
• Quando o último módulo desktop for desligado, o modelo de dados pode ser revisto com calma.

Se o banco não permite acesso direto, ou se parte do legado só se comunica por arquivos e telas, as alternativas estão em como integrar um sistema legado sem API.

Módulo a módulo, com as duas versões no ar

Trocar tudo num fim de semana é a forma mais arriscada de migrar. A alternativa é o padrão conhecido como strangler fig: o sistema novo vai assumindo funções uma a uma, enquanto o antigo continua atendendo o resto.

Como escolher a ordem dos módulos:

1. Comece por algo com valor visível e risco contido. Consultas e relatórios são bons candidatos: dão acesso remoto imediato e não alteram dados.
2. Depois, um fluxo completo e periférico. Um cadastro com poucas dependências ou um processo de um setor específico.
3. Deixe o coração para quando a base estiver madura. Faturamento, fiscal e financeiro entram quando os padrões de integração, permissões e testes já foram exercitados.

Durante a convivência, cada funcionalidade deve ter um lugar oficial. Se o cadastro de clientes já é feito na web, a tela correspondente no desktop fica somente leitura ou é removida. Duas telas editando a mesma coisa com regras diferentes é a receita da divergência.

Outro cuidado: a infraestrutura muda junto. Um sistema web precisa de servidor acessível, HTTPS, backup e monitoramento. Se o banco ainda está num servidor local, vale planejar em paralelo a migração do servidor local para a nuvem, sem misturar as duas mudanças no mesmo dia.

Impressoras, balanças, leitores e outros periféricos

O desktop tem acesso direto à máquina: porta serial, impressora local, leitor conectado por USB. O navegador, por segurança, não tem. É aqui que muitas migrações travam na última hora.

As soluções mais comuns, conforme o periférico:

• Impressoras comuns. Relatórios passam a ser gerados em PDF e impressos pelo navegador. Funciona bem para documentos, mal para rotinas de alto volume.
• Impressoras térmicas e de etiquetas. Precisam de controle fino de layout e velocidade. A saída costuma ser um pequeno agente local, instalado na estação, que recebe o trabalho do sistema web e envia para a impressora na linguagem dela.
• Leitores de código de barras. A maioria funciona como teclado e não exige nada especial. Basta a tela estar preparada para receber a leitura no campo certo.
• Balanças e equipamentos seriais. Também pedem um agente local ou um navegador com suporte à API de porta serial, avaliado caso a caso conforme o ambiente.
• Certificado digital A3 e token. Para assinatura e emissão fiscal, costuma exigir componente local ou a migração da assinatura para o servidor com certificado A1, decisão que envolve também o contador.

O ponto é levantar cada periférico no início, com modelo e uso, e não descobrir na véspera que o depósito imprime etiquetas por um driver que ninguém atualiza há anos.

Atalhos, telas densas e produtividade de quem usa há anos

Um operador experiente num sistema desktop é rápido de um jeito que a maioria das telas web não acompanha. Ele digita o código do produto, aperta Enter, digita a quantidade, F5 grava, e nunca toca no mouse. Trocar isso por uma interface bonita, cheia de espaço em branco e dependente de clique, é garantia de reclamação e de queda real de produtividade.

O que preservar:

• Navegação por teclado completa, com ordem de tabulação pensada e atalhos para as ações mais frequentes, de preferência os mesmos do sistema antigo.
• Telas densas quando o trabalho é denso. Lançamento de pedido com muitos itens pede grade editável, não formulário de uma coluna.
• Pesquisa rápida por código, nome ou parte do nome, com resposta imediata.
• Tempo de resposta baixo em cada gravação. Uma rede lenta que acrescenta espera a cada Enter destrói a vantagem do teclado.

O que pode e deve mudar: telas que ninguém usa, campos que só existem por motivo histórico, fluxos que obrigam a abrir três janelas para uma operação. A migração é a chance de simplificar, desde que a simplificação seja validada com quem opera, com protótipo, antes de virar código.

Treinamento e desligamento da versão antiga

O desligamento do desktop é um projeto em si, e merece um plano:

• Piloto por grupo. Cada módulo novo começa com um grupo pequeno de usuários, que tem canal direto com a equipe de desenvolvimento.
• Treinamento curto e prático, feito no fluxo real de trabalho, com material de consulta rápida.
• Critério de saída claro. O módulo antigo só é desligado quando o novo cobre as regras do inventário, os relatórios usados e os periféricos daquele setor.
• Consulta ao histórico. Dados antigos que não foram migrados precisam continuar consultáveis, nem que seja por uma tela somente leitura.
• Data de desligamento comunicada e cumprida. Deixar o desktop disponível "por via das dúvidas" mantém dois sistemas vivos indefinidamente.

Quando faz sentido, e quando não

Faz sentido quando o acesso remoto virou gargalo, quando a manutenção do desktop depende de uma pessoa ou de tecnologia sem suporte, ou quando a empresa precisa integrar o sistema com parceiros, e-commerce ou aplicativos. Pode não fazer sentido quando o sistema é estável, usado por poucas pessoas num único local e sem necessidade de integração. Nesse caso, estabilizar, fazer backup direito e documentar pode ser a decisão mais inteligente por um bom tempo.

Riscos e como medir o resultado

Os riscos que mais aparecem:

• Regra perdida na tradução de uma tela ou gatilho.
• Queda de produtividade por interface pensada para o mouse.
• Periférico esquecido que trava a operação no dia da virada.
• Convivência sem dono, com duas versões editando o mesmo dado.
• Migração interminável, porque o último módulo difícil nunca é atacado.

Para medir, compare com a linha de base do desktop: tempo para executar as operações mais frequentes, erros e retrabalho, chamados de suporte por módulo, quantidade de usuários ainda dependentes do sistema antigo e disponibilidade de acesso fora do escritório.

Do Delphi ao navegador, com método

Na Pervian Tech, migrações de desktop para web começam com um diagnóstico que mapeia regras, periféricos e uso real antes de qualquer tela, e seguem por módulos, com as duas versões convivendo de forma controlada. É um trabalho de arquitetura de software tanto quanto de desenvolvimento, e cada projeto é sob medida, porque cada legado tem as suas camadas escondidas.

O investimento é definido sob consulta, depois de um diagnóstico inicial gratuito que mostra o tamanho real do sistema e a ordem mais segura de migração. Se o seu sistema desktop já virou um freio, conte como ele funciona hoje.