Transformar sistema desktop em aplicativo

O pedido: "queremos o sistema no celular"

O pedido costuma chegar assim. A empresa tem um sistema desktop que sustenta a operação — pedidos, estoque, financeiro, ordens de serviço — escrito em Delphi, VB6 ou .NET Framework com WinForms, instalado nas máquinas do escritório e ligado a um banco Firebird, SQL Server ou Access na rede local. Funciona. Mas quem está na rua não tem acesso: o vendedor anota o pedido no papel, o técnico liga para o escritório para saber o histórico do cliente, o estoque é conferido por telefone.

A vontade natural é "colocar o sistema no celular". E a primeira descoberta é que isso não é uma conversão, é um projeto — porque o sistema desktop, do jeito que foi construído, não tem nada que um aplicativo consiga usar. Este artigo explica por quê e qual é o caminho que funciona.

Por que não dá para "portar a tela"

A tela de um sistema desktop foi desenhada para monitor de 21 polegadas, teclado e mouse. Uma tela de pedido típica tem cabeçalho com quinze campos, grade de itens com dez colunas, abas, botões de atalho com F2 e F5, e uma pessoa sentada que usa aquilo oito horas por dia. No celular, com o polegar e de pé no cliente, essa tela é inutilizável. O vendedor na rua não precisa de quinze campos: precisa escolher o cliente, buscar o produto, ver preço e saldo e confirmar.

Mas o problema maior não é visual. Num sistema legado típico, a tela é o sistema. A regra de negócio mora dentro do evento OnClick do botão "Gravar": é ali que se calcula o desconto por faixa, se verifica o limite de crédito, se baixa o estoque e se gera o título no financeiro, com consultas SQL escritas direto no formulário. Não existe uma camada separada que diga "gravar pedido" e que outro programa possa chamar.

Por isso as saídas rápidas decepcionam. Acesso remoto pelo celular (área de trabalho remota, ou virtualização do aplicativo) mostra a tela do desktop espremida numa tela de toque, e só funciona com sinal bom. Conversores automáticos de código traduzem a mesma arquitetura para outra linguagem, e o problema continua lá — explicamos neste artigo por que conversor automático não resolve. Servem, no máximo, como paliativo enquanto o caminho certo é construído.

A API é o pré-requisito

O aplicativo precisa de alguém para conversar. Esse alguém é uma API: um serviço no servidor que recebe pedidos como "liste os clientes deste vendedor", "qual o saldo deste produto", "grave este pedido", aplica as regras de negócio e responde. O app cuida da tela; a API cuida da regra e dos dados.

Num sistema legado, construir essa API significa extrair a regra que hoje está espalhada pelas telas. E aqui está o ponto que separa um projeto que dá certo de um que gera inconsistência: a regra da API tem de ser a mesma do desktop. Se o desktop calcula desconto de um jeito e o app de outro, em um mês o financeiro está cheio de diferenças que ninguém sabe explicar.

Para isso, antes de escrever a API, é preciso entender o que o sistema faz de verdade — lendo o código, o banco e o uso real, conversando com quem opera — e registrar essas regras. Mostramos como documentar um sistema legado que não tem documentação; é exatamente o trabalho que vem antes da primeira linha da API. Esse mesmo trabalho é o primeiro passo de uma migração de sistemas legados: a API que nasce para o app é o começo da arquitetura nova.

O que a API resolve de uma vez

Uma regra de negócio num lugar só, que o app, um futuro sistema web e integrações com parceiros podem usar. Autenticação e permissão por usuário. Registro de quem fez o quê. E um ponto de controle entre a internet e o banco de dados da empresa.

Escolha o primeiro caso de uso, não o sistema inteiro

O erro mais caro é tentar levar todas as funções do desktop para o app. O sistema do escritório acumulou anos de telas, relatórios e cadastros; a maior parte delas não faz sentido no celular. O aplicativo começa por uma tarefa — a de quem está fora do escritório e hoje depende de papel, telefone ou planilha.

Imagine uma distribuidora com um ERP em Delphi 7 e banco Firebird, e oito vendedores externos que anotam pedidos num bloco e os passam no fim do dia. O primeiro caso de uso é óbvio: tirar pedido no celular. Para isso a API precisa de pouca coisa — clientes da carteira do vendedor, catálogo com preço e saldo, regra de desconto e limite de crédito, e gravar o pedido no mesmo banco que o ERP lê. Contas a pagar, fiscal, compras e relatórios gerenciais ficam onde estão.

Bons candidatos a primeiro caso de uso têm em comum:

Usuário fora do escritório. Quem está na mesa já tem o desktop; o ganho do app está em quem não tem.
Retrabalho visível. Algo que hoje é anotado e redigitado, com erro e atraso. O antes e depois fica claro para todos.
Poucas regras envolvidas. Uma tarefa que toca três ou quatro regras do sistema, não trinta. A primeira API precisa ser pequena para ser bem feita.
Uso diário. Um app usado todo dia revela problemas rápido e ganha adesão; um app usado uma vez por mês é esquecido.

Outros exemplos típicos: técnico fechando ordem de serviço com foto e assinatura do cliente, motorista confirmando entrega com comprovante, conferência de estoque com leitor de código de barras, gestor aprovando pedido acima do limite.

Offline e sincronização

No escritório, o desktop está sempre na rede. No campo, o sinal cai no subsolo do cliente, na estrada e dentro do galpão. Um app que trava sem internet é abandonado na primeira semana, e o vendedor volta para o bloco de papel.

Funcionar offline exige decisões que o desktop nunca precisou tomar:

O que guardar no aparelho. A carteira de clientes do vendedor e o catálogo, sim; o cadastro inteiro da empresa, não. O que vai para o celular também é uma decisão de segurança.
Como registrar o que foi feito sem rede. O pedido é gravado localmente e entra numa fila de envio, com identificador gerado no próprio aparelho para não duplicar quando reenviado.
Quão desatualizado o dado pode estar. Preço de ontem talvez seja aceitável; saldo de estoque de ontem talvez não. O app precisa mostrar quando foi a última sincronização.
O que fazer em conflito. O último item em estoque foi vendido no app e no balcão ao mesmo tempo. Quem ganha? O pedido entra como pendente? Isso é decisão de negócio, e precisa ser tomada com quem conhece a operação — não descoberta em produção.

A API precisa ser desenhada para isso: aceitar reenvio sem duplicar, devolver só o que mudou desde a última sincronização e responder com clareza quando uma operação feita offline não pôde ser aceita.

Segurança: não exponha o banco

O atalho mais perigoso é ligar o aplicativo direto no banco de dados do sistema legado: abrir a porta do Firebird ou do SQL Server para a internet e colocar usuário e senha do banco dentro do app. Funciona em demonstração e é um risco sério em produção.

Credencial no app é credencial pública. Um aplicativo instalado pode ser descompactado e inspecionado. Qualquer senha embutida nele deve ser considerada conhecida.
Banco exposto é alvo. Servidores de banco acessíveis pela internet são varridos continuamente por robôs atrás de senhas fracas e versões sem atualização — e bancos de sistemas legados costumam estar em versões antigas.
Sem API, não há regra nem limite. Quem tem acesso direto ao banco pode ler e alterar qualquer tabela, não só os clientes da própria carteira.

Com uma API no meio, cada usuário tem o próprio login, com permissões do que pode ver e fazer; o acesso pode ser revogado quando o aparelho é perdido ou o funcionário sai; a comunicação é criptografada; e o banco continua fechado na rede da empresa ou na nuvem, acessível só pela API. É mais trabalho no começo, e é o que permite dormir tranquilo depois.

O caminho incremental: app e desktop lado a lado

Ninguém precisa desligar o sistema desktop para ter um aplicativo. O desenho que funciona é o mesmo da migração incremental de legado (o padrão de estrangulamento):

Entender e documentar as regras e os dados envolvidos no primeiro caso de uso.
Construir a API com essas regras, lendo e gravando no mesmo banco que o desktop usa. O ERP vê o pedido do app como vê qualquer outro.
Construir o app para essa tarefa, testar com um grupo pequeno de usuários reais e ajustar.
Ampliar. Cada novo caso de uso leva mais regras para a API. Aos poucos, a API passa a concentrar a lógica que antes estava presa nas telas.
Substituir o desktop por partes, quando fizer sentido — por um sistema web que usa a mesma API. Ou não: há empresas em que o desktop continua servindo bem ao escritório por muito tempo.

Cada etapa é pequena, entrega algo usável e pode ser revertida sem afetar a operação. O app vira, na prática, a porta de saída do legado: o motivo concreto para começar a modernização, com retorno visível desde a primeira entrega. Em sistemas Delphi e VB6 o caminho tem particularidades — banco BDE ou Paradox, componentes de terceiros, regras em stored procedures — que tratamos nos guias de como migrar um sistema Delphi e de como migrar um sistema VB6.

E a tecnologia do aplicativo?

Para a maioria dos apps de campo, um framework multiplataforma como Flutter ou React Native atende bem: uma base de código para Android e iOS, com acesso a câmera, GPS, leitor de código e armazenamento local para o modo offline. Desenvolvimento nativo (Kotlin e Swift) entra quando o app depende de hardware específico — impressora térmica Bluetooth, leitor dedicado, SDK de fabricante. Se o app é só para a equipe interna, nem sempre precisa estar nas lojas públicas: dá para distribuir de forma privada para os aparelhos da empresa.

A escolha importa, mas importa menos do que a API e o primeiro caso de uso bem escolhido. Detalhamos as opções na página de desenvolvimento de aplicativos Android e iOS.

Perguntas frequentes

Existe ferramenta que transforma um sistema Delphi ou VB6 em aplicativo automaticamente?

Não de um jeito que dê um aplicativo útil. Ferramentas de conversão ou de acesso remoto podem mostrar a tela do desktop no celular, mas o resultado é uma tela feita para mouse e monitor grande espremida num aparelho de toque, que depende de rede o tempo todo. Um app de verdade exige separar a regra de negócio numa API e desenhar as telas para o uso no celular.

Preciso jogar fora o sistema desktop para ter um aplicativo?

Não. O caminho mais seguro é incremental: construir uma API que expõe as funções que o app precisa, lendo e gravando no mesmo banco, e manter o desktop funcionando para quem trabalha no escritório. Com o tempo, mais regras passam para a API, e o desktop pode ser substituído por partes, quando fizer sentido.

O aplicativo pode se conectar direto no banco de dados do sistema?

Não deve. Ligar o celular direto no banco exige expor o servidor de banco na internet e colocar credenciais dentro do app, onde podem ser extraídas. Além disso, a regra de negócio fica sem quem a aplique. O app deve conversar com uma API, que autentica o usuário, valida os dados e só então acessa o banco.

O aplicativo funciona sem internet?

Pode funcionar, se isso for desenhado desde o começo. O app guarda localmente os dados que o usuário precisa, registra as operações feitas sem rede e as envia quando a conexão volta. O trabalho difícil é definir o que acontece em conflito, por exemplo quando um item foi vendido no app e no balcão ao mesmo tempo, e isso é uma decisão de negócio, não só técnica.

Por onde começar para levar o sistema para o celular?

Pela tarefa de quem está fora do escritório e hoje depende de papel, telefone ou planilha: tirar pedido, consultar estoque, fechar ordem de serviço, confirmar entrega. Escolhida a tarefa, levanta-se no sistema legado quais regras e dados ela usa, documenta-se isso e constrói-se a API e a primeira versão do app só para ela.

Conclusão

Levar o sistema para o celular não é converter telas. É dar ao sistema legado algo que ele nunca teve — uma API com as regras de negócio num lugar só — e usar essa API para resolver primeiro o problema de quem está na rua. O desktop continua rodando, o app entrega valor desde a primeira versão, e a empresa ganha, de quebra, o primeiro pedaço da arquitetura que um dia vai substituir o legado.

A ordem é sempre a mesma: entender o sistema, documentar as regras, construir a API e só então o aplicativo.

Quer o seu sistema no celular da equipe?

A NasteSoft entende o sistema legado, constrói a API e o aplicativo — com o desktop funcionando o tempo todo.

Falar com a NasteSoft ↗ Ver o serviço

Do sistema desktop ao aplicativo: como levar o seu sistema legado para o celular