Pular para o conteúdo

PRODUTO 02 · POR TECNOLOGIA

Migração de sistemas antigos, tecnologia por tecnologia

Aplicamos o mesmo método em todos os casos. O que muda é o que costuma travar em cada tecnologia — e para onde levamos o sistema.

Delphi: migrar Delphi para web, para C# ou para Python

O que trava: banco acoplado à interface (a regra de negócio mora no formulário), componentes de terceiros descontinuados, relatórios em ferramenta proprietária e integrações antigas por arquivo.

Para onde levamos: web quando o objetivo é acesso remoto e fim da instalação em máquina; C# quando a equipe interna já é .NET; Python quando o destino inclui processamento de dados ou IA.

Visual Basic 6: migrar VB6 para .NET

O que trava: controles ActiveX sem substituto direto, acesso a dados por bibliotecas fora de suporte e código que assume comportamento do Windows antigo. Como fazemos: migração para .NET por módulo, com o VB6 rodando ao lado — o caminho mais previsível.

Access: migrar Access para web, para SQL ou para MySQL

O que trava: a base cresceu além do que o Access aguenta, várias pessoas usam ao mesmo tempo, e a regra está espalhada entre formulários, macros e consultas. Como fazemos: separamos dado de interface — banco relacional primeiro, interface web depois.

Clipper, FoxPro e arquivos DBF

O que trava: dado em arquivos DBF sem integridade referencial, índices corrompidos e lógica que ninguém compila há anos. Como fazemos: a migração de dados vem primeiro, com conferência registro a registro.

COBOL e mainframe

O que trava: volume, criticidade e regras acumuladas por décadas. Como fazemos: execução em paralelo obrigatória e substituição progressiva — a virada de uma vez é inviável na prática.

Oracle Forms para APEX, Progress 4GL, PowerBuilder e GeneXus

O que trava: ferramentas que geram a interface e a lógica juntas, com pouca separação entre camadas. Como fazemos: extraímos a regra antes de reconstruir a tela, não o contrário.

Para onde levamos: de Oracle Forms para Oracle APEX — hoje o destino mais procurado, e a plataforma que a própria Oracle indica para modernizar Forms, já incluída sem custo adicional de licença nas edições suportadas do Oracle Database.

Java antigo, Struts, JSF, PHP 5 e ASP clássico

O que trava: framework fora de suporte, dependências com vulnerabilidade conhecida e servidor que ninguém quer reiniciar. Como fazemos: começamos pela segurança — aqui esse ganho costuma justificar o projeto sozinho.

SAP: os sistemas e as integrações em volta do ERP

O que trava: o ERP concentra a regra, mas em volta dele existem sistemas satélites, rotinas em planilha e integrações por troca de arquivo que ninguém documentou — e é nesse contorno que o processo trava, não no núcleo do SAP. Como fazemos: levantamos tudo o que entra e sai do SAP, documentamos cada integração e modernizamos o sistema satélite por partes, sem tocar no núcleo do ERP.

Quando a planilha virou o sistema da empresa

Excel e Access com macro sustentando processo crítico é um legado como qualquer outro — sem controle de versão e sem registro de quem mudou o quê. Como fazemos: entendemos a regra, movemos o dado e reconstruímos por partes.

Promoção gradual do tráfego, estágio a estágioNenhum percentual é desenhado: só a proporção visual e o rótulo de estágio. O losango entre uma barra e a seguinte é uma interrupção real — a ampliação nunca é uma rampa automática. Como o tráfego passa do legado para o módulo novo Parte hachurada = sistema legado Parte sólida = módulo novo Estágio 1 — fatia inicial Decisão humana · Indicadores dentro do padrão · Diferenças analisadas e explicadas · Autorização registrada Estágio 2 — fatia ampliada Decisão humana · Indicadores dentro do padrão · Diferenças analisadas e explicadas · Autorização registrada Estágio 3 — maior parte no módulo novo Decisão humana · Indicadores dentro do padrão · Diferenças analisadas e explicadas · Autorização registrada Estágio 4 — tráfego total no módulo novo Enquanto o estágio não é autorizado, o tráfego permanece onde está. Os percentuais de cada estágio são definidos no plano de migração do projeto.
Promoção gradual do tráfego, estágio a estágioNenhum percentual é desenhado: só a proporção visual e o rótulo de estágio. O losango entre uma barra e a seguinte é uma interrupção real — a ampliação nunca é uma rampa automática. Como o tráfego passa do legado para o módulo novo Parte hachurada = sistema legado Parte sólida = módulo novo Estágio 1 — fatia inicial Decisão humana · Indicadores dentro do padrão · Diferenças analisadas e explicadas · Autorização registrada Estágio 2 — fatia ampliada Decisão humana · Indicadores dentro do padrão · Diferenças analisadas e explicadas · Autorização registrada Estágio 3 — maior parteno módulo novo Decisão humana · Indicadores dentro do padrão · Diferenças analisadas e explicadas · Autorização registrada Estágio 4 — tráfego totalno módulo novo Enquanto o estágio não é autorizado, o tráfego permanece onde está. Os percentuais de cada estágio são definidos no plano de migração do projeto.

Promoção gradual do tráfego, estágio a estágio

A troca não acontece de uma vez e nenhum aumento de tráfego é automático: cada ampliação é precedida de decisão humana registrada.

O que isso traz para a sua empresa

A operação não para

O sistema antigo continua no ar durante toda a troca. O usuário final não percebe que o sistema está sendo modernizado — não há “fim de semana da virada” nem dia de risco concentrado.

Volta garantida em cada passo

Se um indicador sair do padrão — erro, tempo de resposta, divergência — o tráfego retorna ao legado imediatamente. Voltar é parte do desenho, não plano de emergência.

Diga qual é a tecnologia

No diagnóstico levantamos o que existe e apontamos o caminho de menor risco para o seu caso.

Respondemos em até 1 hora útil. Confirmação no mesmo dia útil.

Falar pelo WhatsApp