Boa parte das software houses brasileiras carrega um — ou mais — sistemas legados que ainda geram receita. Sistema em Delphi 7 que roda em escritório de contabilidade desde 2003. ERP em Visual FoxPro que controla a indústria do interior do Paraná há 18 anos. Aplicação em Clipper de uma cooperativa que fatura R$ 80 milhões por ano e ninguém quer mexer. Sistema VB6 de uma rede de farmácias que funciona perfeitamente, exceto que o servidor onde roda é de 2009.
O cliente final raramente quer trocar. O sistema funciona. O time conhece. O fluxo está bem amassado. Mas em 2026, três coisas pressionam a software house a fazer algo: hardware envelhecendo (servidor com peças que não se acha mais), exigência de acesso remoto (home office, filial, equipe externa) e LGPD batendo na porta sem o sistema antigo conseguir cumprir o art. 18.
Esse guia foi escrito pra CTO, sócio técnico e arquiteto de software house brasileira que tem cliente nessa situação. Não é texto de "modernização digital total" — é guia prático sobre as 4 estratégias que funcionam pra modernizar sistema legado sem reescrever do zero, e como cada uma se encaixa em cenário específico. Vamos cobrir Delphi, VB6, Clipper, FoxPro, Cobol e qualquer sistema desktop antigo que ainda esteja em produção.
Por que sistema legado virou problema agora
Sistema legado funcional sempre teve um trade-off conhecido: "se não está quebrado, não mexa". Em 2025-2026, esse equilíbrio mudou por 4 fatores convergentes:
1. O servidor está morrendo
Hardware do escritório do cliente tem 8, 10, 15 anos. Disco SAS de 2010 começa a falhar. Memória DDR3 ECC ficou difícil de achar. Sistema operacional é Windows Server 2008 ou 2003 — sem suporte da Microsoft há tempos, sem patch de segurança, sem driver pra hardware novo. Quando o servidor cai pela última vez, não tem pra onde voltar.
2. Cliente exige acesso remoto
Pós-pandemia consolidou home office como exigência. Filial nova precisa do sistema. Vendedor externo quer rodar do hotel. Sistema desktop instalado em estação local não atende — precisa de acesso terminal (RDP), publicação web ou modernização total. Software house que não entrega isso perde cliente pra concorrente que entrega.
3. LGPD não dá pra fingir que não existe
Sistema legado típico não foi pensado pra LGPD. Não tem log de acesso, não permite eliminação seletiva (art. 18, VI), não tem criptografia em repouso, não tem controle granular de permissões. Quando ANPD audita ou cliente B2B faz fiscalização, software house responde como Operadora — e tem que apresentar a infraestrutura.
4. O conhecimento técnico está se aposentando
Quem programa Clipper bem hoje tem 55+ anos. FoxPro mesmo problema. Delphi tem mais comunidade, mas perdeu massa crítica nos últimos 10 anos. Manter sistema com tecnologia que ninguém novo quer aprender é risco operacional crescente. Quando o desenvolvedor que conhece o código aposenta, a software house fica em situação delicada.
Por que reescrita do zero raramente é a solução
O instinto natural é: "vamos reescrever em React + Node + PostgreSQL". Romântico no PowerPoint. Caro e arriscado na prática. Joel Spolsky escreveu o famoso artigo Things You Should Never Do, Part I em 2000 — em 25 anos, a observação ficou mais verdade.
Os 4 problemas reais da reescrita total:
- Custo desproporcional. Sistema legado de 100 mil linhas de Delphi acumula 15-20 anos de regras de negócio. Reescrever fielmente exige mapear cada funcionalidade, testar cada fluxo, validar cada cálculo fiscal. Estimativa típica: 12-36 meses-pessoa pra cobrir um sistema mediano. Pra software house pequena, é o orçamento de 2 anos.
- Conhecimento de negócio escondido no código. Aquele
ifaparentemente sem sentido na rotina de comissão? Foi colocado em 2009 porque o cliente reclamou que vendedor X estava ganhando comissão de venda perdida. Cada linha que parece desnecessária pode estar segurando uma regra que nem o cliente lembra mais. - Período de operação dupla. Você não desliga o sistema velho no dia que o novo entra. Roda os dois em paralelo por 6-12 meses, com bug crítico aparecendo no novo, dado divergente entre os dois, cliente reclamando do que mudou. Custo operacional triplica nesse período.
- Risco de matar o produto. Estatística cruel: cerca de metade dos projetos de reescrita total não termina, ou termina com produto pior que o original. Quando termina, o tempo de pay-back é tão longo que outras iniciativas sofreram.
Reescrita faz sentido em casos específicos: produto vai mudar de modelo de negócio (desktop pra SaaS), tecnologia base é completamente abandonada (Clipper sem nenhum desenvolvedor disponível), cliente final exige funcionalidade que o sistema atual não suporta arquiteturalmente. Pra todo o resto, modernizar sem reescrever é o caminho racional.
As 4 estratégias que funcionam
Modernizar sistema legado tem 4 caminhos práticos, do mais simples ao mais complexo. Cada um resolve dor específica.
Estratégia 1 — Lift-and-shift virtualizando
Você pega o servidor físico do cliente (com Windows Server antigo + sistema legado + banco) e move pra VPS Windows na cloud. Cria uma máquina virtual com mesmo SO (ou mais novo, compatível), instala o sistema legado lá, copia o banco. Cliente continua acessando via rede local, agora com servidor que é provedor cloud, não a torre na sala da diretoria.
O que resolve: hardware morrendo, falta de redundância, dificuldade de manutenção física, backup inadequado, escalabilidade. Sistema continua exatamente o mesmo — visualmente, comportamentalmente, fluxo idêntico.
O que NÃO resolve: acesso remoto pra equipe fora do escritório (sistema continua sendo desktop em rede LAN), modernização técnica do código, conformidade LGPD do sistema (mas resolve da infraestrutura), interface antiquada.
Quando faz sentido: primeiro passo de qualquer modernização. Cliente em situação de "servidor está morrendo e precisa sair daqui". Lift-and-shift é o stepping stone que permite estratégias mais ambiciosas depois.
Tempo típico: 1-3 dias. Tempo de copiar banco e VHD do servidor antigo, configurar rede, virar.
Estratégia 2 — RDP / RDS / Terminal Services
O salto qualitativo. Em vez do sistema desktop estar instalado nas estações dos usuários, ele fica instalado em UM servidor (na cloud), e os usuários acessam via Remote Desktop Protocol (RDP) ou Remote Desktop Services (RDS). Cada usuário enxerga o sistema rodando como se fosse local, mas tudo está num servidor central.
Tecnicamente, RDS suporta múltiplos usuários simultâneos no mesmo Windows Server (Terminal Services Mode). Cada um tem sessão isolada, mas roda no mesmo servidor.
O que resolve: acesso remoto de qualquer lugar (home office, filial, hotel, celular), instalação centralizada (atualizar sistema = atualizar 1 servidor, não 200 estações), redução de complexidade na ponta (usuário só precisa de cliente RDP — Microsoft Remote Desktop, jump.desktop, etc).
O que precisa cuidar: licenciamento Windows Server SPLA + CAL RDS por usuário, latência (rede do cliente precisa ser razoável — pacote indo e voltando do datacenter), banda (cada sessão consome 50-300 kbps idle, 1-3 mbps em uso intenso de tela).
Quando faz sentido: sistema desktop com usuários em múltiplos locais, equipe que precisa acessar de fora do escritório, software house que quer entregar acesso uniforme sem reescrever pra web. Solução clássica pra sistema em Delphi, VB6, FoxPro que precisa virar acessível remotamente.
Tempo típico: 1-2 semanas. Tempo de provisionar Windows Server, configurar RDS, ajustar políticas de sessão, treinar usuários no cliente RDP.
Estratégia 3 — Arquitetura híbrida
Quando o banco de dados é grande demais, ou tem dependência específica de hardware/rede local, divide-se a aplicação em duas camadas. Banco fica no cliente (servidor local, mantido), frontend roda na cloud (servidor RDS), conectados por VPN ou conexão dedicada.
Variantes da arquitetura híbrida:
- Frontend desktop em RDP cloud, banco em SQL Server local — funciona quando latência LAN é crítica
- Aplicação web nova em cloud (frontend e API), banco legado mantido — Strangler que coexiste com base antiga
- Sistema legado em RDS cloud, exposição API REST nova nessa cloud — frontend novo (mobile, web) consome API, sistema antigo continua intocado
O que resolve: casos onde lift-and-shift inteiro não funciona (latência rede, integração local específica, regulação que exige dado físico no cliente). Permite progresso parcial sem mover tudo.
O que precisa cuidar: complexidade operacional (dois ambientes pra monitorar), VPN site-to-site bem configurada, backup de ambos lados.
Quando faz sentido: banco enorme com transações intensivas, integração específica com hardware local (relógio de ponto, leitora SAT, etc), regulação setorial específica que pede dado em instalação física da empresa.
Estratégia 4 — Strangler Pattern (modernização gradual)
Conceito popularizado por Martin Fowler. Em vez de reescrever do zero, você "estrangula" o sistema legado módulo a módulo. Cada novo módulo é construído em tecnologia moderna (web, API REST, cloud-native). Cada módulo legado vai sendo aposentado conforme o novo cobre a funcionalidade.
Implementação típica em 5 etapas:
- Identificar módulo de menor risco e maior valor. Em sistema de gestão, geralmente é "consulta de pedido" ou "extrato financeiro" — leitura, sem regra crítica de negócio.
- Construir API que expõe os dados do banco legado. Em Delphi pode ser DataSnap, em qualquer sistema dá pra colocar uma API REST genérica que lê o banco.
- Construir frontend web/mobile do módulo. Consome a API, exibe dados. Usuário acessa pelo navegador.
- Migrar usuários gradualmente. Primeiro grupo piloto. Bug aparece, ajusta. Funciona, expande.
- Repetir pro próximo módulo. 12-36 meses depois, sistema legado tá só com 10-20% das funcionalidades originais. Continuar ou desligar de vez é decisão comercial.
O que resolve: modernização contínua sem big bang. Time aprende tecnologia nova trabalhando. Cliente vê valor a cada módulo. Risco distribuído ao longo do tempo.
O que precisa cuidar: sincronização entre sistema novo e legado durante a transição, dados em duas fontes (cuidado com inconsistência), políticas de qual sistema tem autoridade sobre qual dado.
Quando faz sentido: sistema com horizonte de uso 5-10 anos, software house com time disposto a modernizar continuamente, cliente final que aceita evolução gradual em vez de revolução. É a estratégia mais sustentável a longo prazo.
Matriz de decisão: qual estratégia escolher
Depende de 3 variáveis: dor primária do cliente, recursos disponíveis na software house, horizonte do produto.
| Cenário | Estratégia recomendada |
|---|---|
| Servidor do cliente está morrendo, precisa sair em semanas | Lift-and-shift imediato. Pode evoluir depois. |
| Cliente exige acesso remoto (home office, filial) | RDP/RDS direto. Resolve em 2 semanas. |
| Banco enorme, latência LAN é crítica, dado precisa ficar no cliente | Híbrido. Banco local + frontend cloud. |
| Cliente quer interface moderna (web/mobile) sem perder histórico | Strangler. Modernizar módulo a módulo. |
| Sistema legado em fim de ciclo, cliente vai migrar pra outro sistema em 2-3 anos | Lift-and-shift só. Não vale investir em modernização se vai descontinuar. |
| Software house quer reduzir custos operacionais, sistema funciona bem | Lift-and-shift + RDP. Modernização gradual depois. |
| Concorrente lançou versão web, cliente vai trocar de fornecedor se ficar parado | Strangler com prioridade nas funcionalidades em risco. |
Em prática, software house madura combina estratégias: lift-and-shift hoje (resolve agora), RDP em 1 mês (acesso remoto), Strangler ao longo dos próximos 24 meses (modernização sustentável).
Aspectos técnicos críticos
Modernizar sistema legado em Delphi, VB6, Clipper ou FoxPro tem detalhes técnicos que costumam pegar quem faz pela primeira vez:
Licenciamento Windows Server e RDS
Sistema desktop legado tipicamente roda em Windows. Quando vai pra cloud, você precisa de:
- Licença Windows Server — modelo SPLA (Service Provider License Agreement) cobrado pelo provedor cloud, mensalmente, por servidor
- CAL (Client Access License) de RDS por usuário se for Terminal Server
- Licenças de banco se usa SQL Server (Standard ou Enterprise dependendo do uso) — Express é gratuito mas com limites
Audaks oferece licenciamento SPLA conforme o uso, sem capex inicial.
Performance de aplicação desktop em cloud
Delphi, VB6, FoxPro foram desenhados pra rodar em rede local com latência <1ms. Quando o frontend desktop roda na cloud (via RDP) e o banco também na cloud, a aplicação se comporta nativamente — porque tudo é local pro servidor cloud. Quando o banco fica local e o frontend na cloud (ou vice-versa), latência WAN pode estourar timeout de aplicação que assume LAN.
Antes de virar produção: teste com banda real, teste com pico de uso, monitore queries que ficam lentas em alta latência.
Backup do sistema legado
Sistema legado raramente tem estratégia de backup decente. Tipicamente: cópia diária pra HD externo, manual, sem teste de restore. Modernizar a infraestrutura sem modernizar o backup é meio caminho. Audaks oferece backup empresarial que cobre Windows Server, banco SQL Server/MySQL/Firebird (comum em Delphi), e ainda M365 do cliente final.
Conformidade LGPD do sistema legado
Sistema sem controle granular de acesso, sem log, sem criptografia em repouso, é desafio de conformidade. Possíveis mitigações sem reescrever:
- Criptografia de disco no servidor (Windows BitLocker ou criptografia do storage)
- Log de acesso ao servidor RDP (já vem do Windows)
- Política de senha forte no AD/local
- Backup com retenção configurada e purge seletivo (via Audaks Backup gerenciado)
Não substitui controle dentro do sistema, mas atende grande parte dos itens que ANPD verifica.
Segurança em ambiente RDP exposto
RDP exposto direto na internet é vetor clássico de ataque. Brute-force, exploits de vulnerabilidades antigas. Boas práticas:
- RDP nunca direto. Sempre por VPN ou RD Gateway
- MFA obrigatório (Microsoft Authenticator, Duo)
- Bloqueio por IP (whitelist do cliente)
- Atualização do Windows Server (SO atual: 2019 ou 2022)
- Monitoramento de tentativas de login
Cenários típicos (não cases reais, mas situações que ocorrem)
Pra dar concretude, alguns cenários comuns que software house enfrenta:
Cenário 1 — Escritório de contabilidade com sistema em Delphi 7
Software house mantém ERP contábil em Delphi 7 desde 2003. 60+ clientes. Cada cliente tem servidor Windows na própria empresa. Cliente A teve servidor parando, ligou pra software house desesperado.
Solução: Lift-and-shift pra VPS Windows na Audaks em 2 dias. Sistema continua igual, agora com backup incluído e suporte engineer 24/7. Cliente paga R$ 380/mês ao invés de manter servidor próprio. Software house cobra setup R$ 1.500 + R$ 80/mês de gestão. Cliente sai feliz, software house aumenta margem.
Cenário 2 — Indústria com FoxPro precisando home office
Indústria de 80 funcionários, sistema de PCP em Visual FoxPro. Pandemia obrigou home office. Sistema só rodava em estação local. Pessoas começaram a usar TeamViewer e AnyDesk caoticamente.
Solução: RDS em servidor dedicado Audaks. 30 usuários simultâneos. Acesso por RD Gateway com MFA. Cada estação remota só precisa de Microsoft Remote Desktop. Software house cobra projeto de migração + mensalidade de gestão. Cliente economiza no caos de suporte que tinha.
Cenário 3 — Cooperativa em Clipper modernizando gradualmente
Cooperativa rural com sistema em Clipper de 1995. Funciona perfeitamente, mas direção quer dashboard moderno, app mobile pro associado, integração com APIs de mercado. Reescrita seria 24 meses, R$ 1.5 milhão.
Solução: Strangler. Sistema Clipper continua rodando (em RDS Audaks pra primeiro passo de migração de hardware). Software house constrói camada de API moderna que lê o banco DBF. Frontend mobile e dashboard web consomem a API. Em 18 meses, cooperativa tem experiência moderna sem trauma de migração total.
Como a Audaks ajuda software house nesse processo
Software house brasileira que mantém sistema legado tem 4 necessidades de infraestrutura específicas:
- Servidor Windows licenciado. SPLA via Audaks, sem capex. VPS Windows ou dedicado Windows dependendo do volume.
- Suporte engineer que entende Windows Server e RDP. Não chatbot, não atendente em inglês. Engenheiro brasileiro 24/7 que já viu Delphi rodando em Windows Server 2003 (e migrou pra 2022).
- Backup adequado de sistema legado. Backup empresarial que cobre Windows Server completo, banco SQL Server/Firebird/Oracle, retenção configurável, anti-ransomware.
- NF brasileira pro cliente final. Software house cobra do cliente em Real, com NF da hospedagem da Audaks. Contábil agradece.
Audaks já atende dezenas de software houses brasileiras com sistemas legados rodando em produção. Engenheiros nossos conhecem Delphi, VB6, FoxPro, sistema de ponto SAT, leitora fiscal — porque tem cliente que precisa hospedar isso. Pra quem está saindo de servidor próprio ou de provedor estrangeiro, processo de migração é assistido pelo nosso time.
Próximos passos
Se você é sócio técnico ou CTO de software house brasileira com sistema legado em produção, aqui está o roteiro pra essa semana:
- Lista os sistemas legados que você mantém. Quantos clientes hospedam em servidor próprio? Quais tecnologias (Delphi, VB6, Clipper, FoxPro, Cobol)? Qual o estado do hardware deles?
- Identifica o cliente em maior risco. Servidor mais antigo, dependência mais crítica, dor mais aguda. É seu ponto de partida.
- Define a estratégia. Lift-and-shift pra resolver o problema imediato? RDS pra ganhar acesso remoto? Strangler pra modernização sustentável? Use a matriz de decisão.
- Conversa com a Audaks. Engineer mapeia o ambiente atual, propõe equivalência em cloud brasileira, monta proposta de migração assistida. Ambiente padrão (até 5 servidores) é incluído no contrato.
Marque uma conversa com nosso time. Ou conheça nossa página dedicada para software house brasileira.
Perguntas frequentes
Sistema em Delphi 7 ainda dá pra hospedar em cloud?
Dá. Delphi 7 (de 2002) gera executável Win32 que roda em Windows Server moderno (2019, 2022). Lift-and-shift do servidor antigo pra VPS Windows na Audaks é direto: copia o executável, copia o banco (Firebird, Oracle, SQL Server, Paradox), configura. Funcionou em servidor antigo, continua funcionando em servidor novo. Audaks já hospeda dezenas desses cenários.
VB6 ainda funciona em Windows Server moderno?
Funciona. VB6 runtime ainda é fornecido pela Microsoft com Windows. ActiveX controls específicos podem dar trabalho, mas com testes, geralmente roda. Mais comum: o sistema VB6 vai pra RDS, usuário acessa via Remote Desktop, frontend nem fica desktop nas estações.
Como migrar sistema em Clipper sem perder os dados?
Clipper geralmente usa banco DBF (dBase, FoxPro). Migração: copia toda a estrutura de pastas DBF do servidor antigo pro novo, executa o sistema, valida. Cuidado com travamento de arquivo (DBF não suporta concorrência alta) — em Audaks com SSD NVMe, performance melhora muito comparado a HD antigo. Conversão pra SQL Server ou PostgreSQL é etapa subsequente, fazendo Strangler.
Quanto tempo leva pra migrar sistema legado pra cloud?
Lift-and-shift simples: 1-3 dias. RDS: 1-2 semanas. Strangler é projeto contínuo de 12-36 meses. Audaks tipicamente faz lift-and-shift em janela de fim de semana — sexta começa, segunda manhã sistema rodando na cloud sem usuário sentir.
Preciso de Windows Server ou Linux?
Sistema desktop em Delphi/VB6/FoxPro/Clipper exige Windows Server. Não tem como rodar em Linux nativamente (Wine pode resolver casos pontuais, mas não pra produção). Audaks oferece Windows Server 2019 e 2022 com licenciamento SPLA — você paga conforme usa, sem capex.
Como lidar com licenças do sistema antigo na cloud?
Sistema customizado da software house geralmente tem ativação por chave/máquina. Migração pra cloud exige nova ativação (novo hardware = nova chave). Software house provê isso ao cliente. Pra bibliotecas terceiras (relatórios, componentes ActiveX), pode exigir relicenciamento — verifica caso a caso.
Sistema funciona offline. Como fica em cloud?
Sistema desktop offline (estação local sem rede) é caso difícil. Se cliente exige operação sem internet, nem cloud nem RDP resolvem. Solução: manter instalação local + sincronizar dados periodicamente com cloud (estratégia híbrida). Comum em frente de caixa de supermercado, bomba de combustível, etc.
RDP é seguro pra produção?
RDP exposto direto na internet, não. RDP atrás de RD Gateway ou VPN, sim — é solução padrão da Microsoft pra Terminal Services em escala. Adicione MFA (Microsoft Authenticator, Duo, Authy) e está em nível adequado de segurança. Audaks configura tudo isso por padrão pra cliente que contrata RDS.
Como cobrar do cliente final pela hospedagem?
Modelos comuns: (a) cobrar mensalidade fechada incluindo hospedagem, software house fica com diferença; (b) cobrar setup + mensalidade de hospedagem destacada na fatura, cliente vê o custo da infra; (c) revenda direta — cliente assina contrato com a Audaks, software house cobra só pelo software e gestão. Os 3 funcionam, depende do seu fluxo comercial.
E se meu cliente não quer mexer no sistema antigo?
Cliente B2B brasileiro que tem sistema funcionando há 15 anos raramente quer mudar por iniciativa própria. Mudança chega quando algo quebra (servidor) ou quando exigência externa aparece (LGPD, home office). Software house deve estar preparada com estratégia clara — quando o cliente ligar dizendo "servidor parou" ou "preciso acessar de casa", você já tem proposta pronta.
Vocês ajudam na migração ou eu preciso ter time DevOps?
Ajudamos. Engenheiro Audaks faz o desenho da migração junto com seu time, monta o ambiente Windows Server, configura RDS se for o caso, acompanha a janela de virada. Você executa migração de dados (você conhece o sistema legado, nós conhecemos a infra). Pra ambientes complexos com vários sistemas legados de clientes diferentes, fazemos serviço dedicado de migração assistida.
Sistema em Cobol também roda em cloud?
Roda. Cobol moderno (Micro Focus, Fujitsu, GnuCOBOL) tem versões Windows e Linux. Cobol legado de mainframe é caso específico que exige análise. Mas Cobol de servidor médio empresa, sim — Audaks hospeda casos assim. Geralmente é parte de Strangler porque achar desenvolvedor Cobol novo é um desafio à parte.