ERP em nuvem: a migração mais cara e mais adiada das empresas

Todo departamento de tecnologia tem um sistema que ninguém quer abrir. Costuma ser o de gestão empresarial: o software que registra pedido, estoque, nota fiscal, folha e contabilidade no mesmo lugar. Ele é antigo, é lento em alguns pontos e funciona bem o suficiente para que mexer nele pareça imprudente.

É também o sistema cuja migração é adiada com mais frequência. Não porque a alternativa em nuvem não exista, mas porque o custo real da troca não está na licença nem na infraestrutura. Está na camada de customizações acumuladas e nos processos que foram moldados por elas ao longo dos anos.

Apuração · o que é verificável

O que aconteceu

Um sistema de gestão empresarial integra em uma base comum os registros que sustentam a operação: cadastro de produtos e clientes, movimentação de estoque, obrigações fiscais, contas a pagar e a receber. A vantagem do modelo é justamente a base única, que evita conciliação manual entre departamentos.

Essa mesma integração cria uma dependência forte. Como todos os processos leem e escrevem no mesmo conjunto de tabelas, mudanças de estrutura afetam áreas que aparentemente nada têm a ver entre si. Alterar um campo de cadastro pode quebrar um relatório fiscal escrito anos antes por outra equipe.

A oferta em nuvem muda o modelo de entrega: em vez de uma instalação sob controle da empresa, o software é operado pelo fornecedor e atualizado em ciclos que o cliente não define. A troca é de controle por manutenção contínua, e essa troca é o centro da decisão.

Contexto

Sistemas instalados na própria empresa foram, por muito tempo, a única opção viável para operações com exigência fiscal complexa. Isso permitiu um grau de adaptação profundo: campos adicionais, rotinas próprias, relatórios sob medida e integrações escritas para atender a uma exigência específica de um cliente ou de um órgão.

Cada adaptação resolveu um problema real e criou uma amarra. Quando o fornecedor libera uma nova versão, cabe à empresa reconciliar as próprias modificações com as mudanças recebidas. Quanto maior a camada própria, mais caro fica atualizar - e mais tentador fica ficar parado em uma versão antiga.

O modelo em nuvem inverte essa lógica. A atualização é contínua e comum a todos os clientes, o que reduz o esforço de manutenção e, ao mesmo tempo, limita o quanto cada empresa pode alterar o comportamento padrão. A adaptação migra da modificação interna para a extensão por interface.

Por que a customização vira dívida

A customização raramente é registrada como investimento com prazo de validade. Ela entra como solução de um problema urgente e permanece indefinidamente, mesmo depois que a razão original deixou de existir. Muitas empresas descobrem, na primeira tentativa de migrar, que ninguém sabe explicar por que certa rotina existe.

Isso transforma o levantamento inicial em trabalho arqueológico. É preciso separar o que é exigência legal, o que é regra de negócio deliberada e o que é hábito consolidado que sobreviveu por inércia. Só a primeira categoria é inegociável; as outras duas são candidatas naturais a serem abandonadas.

O erro comum é pular essa separação e pedir ao novo sistema que reproduza o comportamento antigo em detalhe. Quando isso acontece, a empresa recria a mesma camada de customização em uma plataforma que foi projetada para não tê-la - e paga duas vezes pelo mesmo problema estrutural.

Os caminhos de migração e seus custos

Há basicamente três estratégias. Levantar e mover a instalação existente para infraestrutura remota preserva tudo e não resolve nada além de responsabilidade sobre hardware. É o caminho mais rápido e o que menos reduz dívida técnica, mas serve quando o objetivo é apenas sair de um parque físico obsoleto.

A segunda é a substituição completa, com adoção do processo padrão do novo sistema e ajuste da operação a ele. Tem o maior potencial de simplificação e o maior risco de parada, porque exige que a empresa mude a forma de trabalhar no mesmo período em que troca a ferramenta.

A terceira é a migração por módulos, mantendo os dois sistemas em operação durante um intervalo. Reduz o risco de parada total e cria um problema próprio: enquanto durar a convivência, é preciso sincronizar cadastros e evitar que a mesma informação exista em duas versões divergentes.

Interpretação editorial da sysINFO

Análise sysINFO

A leitura da sysINFO é que o adiamento raramente é irracional. Quando o sistema atual sustenta o faturamento e a alternativa exige mudar processo, treinar pessoas e assumir risco de parada, esperar é uma decisão defensável - desde que o custo do adiamento seja medido, e não apenas sentido.

O que costuma faltar é essa medição. Versões antigas restringem contratação, dificultam integração com serviços novos e concentram conhecimento em poucas pessoas. Esses custos não aparecem em nenhuma linha de orçamento, mas cobram na velocidade com que a empresa consegue responder a qualquer mudança externa.

Vale registrar que esta seção é interpretação editorial da sysINFO, não relato de fato. O que é verificável é o mecanismo: customização profunda encarece atualização, e atualização adiada acumula distância. A avaliação sobre quando o adiamento deixa de compensar é a nossa leitura desse mecanismo.

Recorte brasileiro

Impacto para o Brasil

A complexidade fiscal brasileira é o fator que mais pesa aqui. Regras que variam por estado, por regime tributário e por tipo de operação exigem que o sistema acompanhe alterações normativas com frequência alta. Isso torna a manutenção contínua um argumento forte a favor do modelo operado pelo fornecedor.

Em contrapartida, muitas adaptações locais foram escritas exatamente para atender a essas regras, e nem sempre existem como recurso padrão em plataformas concebidas fora do país. A avaliação precisa distinguir o que a plataforma resolve nativamente do que dependerá novamente de desenvolvimento sob medida.

Há também a dimensão de proteção de dados. Um sistema de gestão concentra dados pessoais de clientes, fornecedores e empregados, o que coloca a migração sob as obrigações de finalidade, retenção e segurança da legislação brasileira. Contrato, local de processamento e regra de descarte precisam ser definidos antes.

Agenda de acompanhamento

O que observar agora

A decisão costuma ser tomada uma vez por década e condiciona tudo o que vem depois. Alguns sinais ajudam a avaliar se o adiamento continua sendo prudente ou se já virou acúmulo de risco, especialmente em empresas cuja operação depende de integrações com parceiros externos e obrigações acessórias.

• Se o fornecedor atual mantém suporte e atualização fiscal para a versão instalada na empresa.
• Quantas pessoas conseguem explicar, sem consultar código, por que cada customização existe.
• Se as integrações com bancos, transportadoras e órgãos públicos dependem de rotinas próprias frágeis.
• Como o contrato de nuvem trata saída de dados, formato de exportação e prazo de devolução.