# Como migrar um sistema Access para a web sem parar a operação

> Como migrar um sistema Access ou Excel com VBA para a web por etapas: achar as regras escondidas nas macros, validar os dados e trocar módulo a módulo.

Fonte: https://pervian.tech/blog/modernizar-sistema-em-access-ou-vba · Pervian Tech · publicado em 2026-10-01

Começou como uma planilha com algumas macros, ou um banco Access montado por alguém do financeiro que "entendia de computador". Anos depois, aquele arquivo calcula comissão, controla estoque, gera os pedidos de compra e alimenta o relatório que a diretoria olha toda segunda-feira. Ninguém planejou que ele virasse o coração da operação. Ele virou.

O sinal de alerta costuma ser um susto: o arquivo que não abre depois de uma queda de energia, o "registro bloqueado por outro usuário" na hora do fechamento, ou a notícia de que a pessoa que criou tudo vai sair da empresa. Nesse momento, a pergunta deixa de ser "se" e passa a ser **como migrar um sistema Access para a web sem perder o que ele faz e sem parar a operação**.

A resposta curta: levantar o que o sistema realmente faz (inclusive o que está escondido nas macros), migrar os dados com validação contra o sistema antigo e substituir por módulos, com os dois convivendo por um período controlado. O restante deste texto detalha cada etapa e vale também para Excel com VBA e FileMaker, que têm problemas muito parecidos.

## O sistema em Access que a empresa não pode perder

Antes de falar em riscos, vale reconhecer o mérito. Um sistema em Access ou VBA que sobreviveu anos resolve um problema real, do jeito que a empresa trabalha. Ele foi moldado pelo uso: cada botão, cada consulta e cada relatório existe porque alguém precisou dele.

Isso tem duas consequências para a migração:

- **O sistema antigo é a melhor especificação que existe.** Nenhuma reunião de levantamento vai lembrar de tudo o que ele faz. O próprio arquivo, com suas tabelas, consultas e módulos de código, é a fonte mais confiável.
- **Os usuários são rápidos nele.** Quem lança cinquenta pedidos por dia decorou atalhos e a ordem dos campos. Uma tela nova "mais bonita" que obriga a usar o mouse pode piorar a produtividade.

Se a empresa ainda está no estágio anterior, com planilhas soltas sem macros e sem banco, o caminho é um pouco diferente e está descrito em [como substituir planilhas por um sistema](https://pervian.tech/blog/substituir-planilhas-por-sistema).

## Riscos: arquivo corrompido, acesso simultâneo, autor saiu

Os riscos de um sistema crítico em Access ou VBA são conhecidos e se repetem de empresa para empresa.

### Arquivo corrompido

O Access guarda tudo num arquivo único (.mdb ou .accdb), normalmente numa pasta compartilhada da rede. Uma queda de energia, uma conexão Wi-Fi instável ou uma máquina desligada no meio de uma gravação podem corromper esse arquivo. Às vezes o "compactar e reparar" resolve. Às vezes perde-se o trabalho do dia, ou mais, se o backup não estava sendo feito como todos imaginavam.

Há também um limite físico: um arquivo Access não passa de 2 GB. Empresas que guardam anos de movimentação, ou anexam imagens e PDFs no próprio banco, chegam perto desse teto e começam a arquivar dados "em outro arquivo", o que fragmenta a informação.

### Acesso simultâneo

O Access foi pensado para poucos usuários ao mesmo tempo. Com o crescimento da equipe aparecem os bloqueios de registro, a lentidão em horário de pico e os conflitos de edição. No Excel com VBA costuma ser pior: em geral só uma pessoa por vez consegue editar o arquivo com macros na pasta da rede, e o resto da equipe abre como somente leitura ou trabalha em cópias que depois precisam ser conciliadas na mão. Quando o problema é só a rotina automatizada, compare [macro VBA ou Python](https://pervian.tech/blog/macro-vba-ou-python).

Acesso fora do escritório também vira improviso: área de trabalho remota, VPN, cópia do arquivo no pen drive do vendedor. Cada improviso é uma nova chance de dado divergente.

### O autor saiu

É o risco mais comum e o menos discutido. O [sistema foi construído por uma pessoa](https://pervian.tech/blog/sistema-dependente-de-um-programador), sem documentação, com código VBA que só ela entendia. Quando ela sai, a empresa herda uma caixa-preta. Ninguém sabe por que o cálculo de frete tem uma exceção para determinado estado, ou por que um relatório precisa ser gerado antes de outro.

Esse cenário tem um roteiro próprio, que vale para qualquer tecnologia: [como assumir um sistema legado sem documentação](https://pervian.tech/blog/assumir-sistema-legado-sem-documentacao).

### Segurança e controle de acesso

Senha no arquivo Access ou na planilha protege pouco, e o código VBA pode ser lido por quem abre o arquivo, a menos que tenha sido protegido. Na prática, quem tem acesso à pasta da rede tem acesso a todos os dados, incluindo dados pessoais de clientes e funcionários, o que pesa na adequação à LGPD. Também não há registro confiável de quem alterou o quê, o que complica auditorias e investigações internas.

## Regras de negócio escondidas em macros

O ponto em que migrações de Access e VBA mais falham é o mesmo: **regras de negócio que ninguém sabe que existem**. Elas costumam estar em cinco lugares:

- **Módulos e funções VBA.** O [cálculo de comissão com faixas por vendedor](https://pervian.tech/blog/sistema-de-comissao-de-vendedores), o arredondamento específico de impostos, a regra que bloqueia pedido de cliente com título vencido.
- **Eventos de formulário.** Código que roda "ao sair do campo" ou "antes de atualizar": preenche campos automaticamente, valida combinações, muda o status do pedido. Para o usuário, isso parece comportamento natural da tela.
- **Consultas salvas.** Consultas de atualização e exclusão que rodam em sequência, às vezes disparadas por um botão chamado "Fechar mês". A ordem importa e raramente está documentada.
- **Macros automáticas.** No Access, uma macro chamada AutoExec roda quando o arquivo abre. Ela pode importar arquivos, apagar registros temporários ou atualizar cotações sem que ninguém perceba.
- **Fórmulas de planilha.** No Excel, parte da lógica está em fórmulas espalhadas por abas ocultas, validações de dados e formatação condicional que funciona como alerta.

Uma frase que deve acender o alerta no levantamento: "o sistema já faz isso sozinho". Toda vez que alguém diz isso, existe uma regra a encontrar.

## Levantando o que o sistema realmente faz

O levantamento combina três fontes. Nenhuma delas, sozinha, é suficiente.

### 1. Ler o arquivo, não só as telas

Um engenheiro abre o Access ou a planilha e cataloga tudo: tabelas e relacionamentos, consultas, formulários, relatórios, módulos VBA, macros e vínculos com arquivos externos. Para cada trecho de código relevante, registra em linguagem de negócio o que ele faz. "Função CalcDesc" não serve. "Desconto máximo de vendedor júnior é menor que o de sênior, e acima do limite o pedido vai para aprovação do gerente" serve.

### 2. Observar quem usa

Acompanhar as pessoas no trabalho real revela o que o código não mostra: a planilha auxiliar que alimenta o Access toda manhã, o relatório exportado e ajustado à mão antes de ir para o contador, o campo usado para algo diferente do nome dele ("observação" que na verdade guarda o número da nota de entrada).

### 3. Mapear as integrações informais

Sistemas em Access e VBA quase sempre conversam com o resto da empresa por arquivos: importam o extrato do banco, exportam um arquivo para o sistema fiscal, leem uma planilha do fornecedor. Cada uma dessas pontes precisa de um destino no sistema novo.

O resultado é um **inventário de funcionalidades e regras**, priorizado por criticidade. É esse documento que guia a migração e evita a frase "o sistema antigo fazia isso" descoberta só depois da virada.

## Migração de dados com validação

Dados de Access e Excel raramente estão limpos. É comum encontrar:

- clientes duplicados com grafias diferentes;
- datas digitadas como texto, em formatos variados;
- CNPJ e CPF com e sem pontuação, alguns inválidos;
- códigos de produto reaproveitados ao longo dos anos;
- campos obrigatórios vazios em registros antigos;
- valores calculados gravados na tabela que não batem com o cálculo atual.

A migração segura segue um roteiro:

1. **Extrair** os dados para uma área de trabalho, sem mexer no arquivo em produção.
2. **Perfilar**: contar registros, achar duplicados, nulos e formatos fora do padrão.
3. **Decidir as regras de limpeza junto com a área de negócio.** Qual dos dois cadastros duplicados prevalece? Registros de antes de determinado ano precisam vir ou podem ficar num arquivo histórico só para consulta?
4. **Carregar no banco novo** com as regras aplicadas por script, que pode ser executado de novo quantas vezes for preciso.
5. **Conferir contra o sistema antigo**: total de registros por tabela, soma de valores por mês, saldo de estoque por produto, títulos em aberto por cliente. Se o faturamento de março soma diferente nos dois sistemas, a migração não está pronta.

O passo 5 é o que separa uma [migração de dados confiável](https://pervian.tech/blog/migracao-de-dados-entre-sistemas) de uma aposta. As conferências devem ser definidas antes da carga, com números que a área financeira e a operação reconhecem.

## Migrar por módulos ou de uma vez

Na maioria dos casos, a recomendação é [migrar por módulos](https://pervian.tech/blog/modernizacao-gradual-de-sistemas). Mas há situações em que a virada única faz sentido.

| Critério | Por módulos | De uma vez |
|---|---|---|
| Tamanho do sistema | Muitas telas e processos | Poucas telas, escopo pequeno |
| Risco operacional | Baixo, falha afeta uma parte | Alto, falha afeta tudo |
| Tempo até o primeiro ganho | Curto, o primeiro módulo já entrega valor | Longo, só no fim |
| Complexidade técnica | Maior, exige sincronizar dados entre os dois | Menor, um único corte |
| Treinamento | Gradual, uma área por vez | Concentrado, todos ao mesmo tempo |
| Indicado quando | O sistema é crítico e grande | O sistema é simples e a equipe é pequena |

### E o meio-termo de tirar só os dados do Access?

Uma alternativa comum é manter as telas no Access e mover as tabelas para um banco de dados servidor, como o SQL Server, com o Access apenas ligado a elas. Isso reduz o risco de corrupção e o limite de 2 GB, e pode ser uma boa medida de emergência enquanto o projeto maior não começa. Mas não resolve o acesso fora do escritório, não tira as regras de dentro do VBA e mantém a dependência de quem entende o arquivo. Vale como ponte, raramente como destino. Refazer tudo numa plataforma low-code é outra rota, com limites discutidos em [low-code ou desenvolvimento sob medida](https://pervian.tech/blog/low-code-ou-desenvolvimento-sob-medida).

### Como escolher o primeiro módulo

O primeiro módulo deve ter **valor visível e risco controlado**. Bons candidatos:

- a parte que mais sofre com acesso simultâneo, como o lançamento de pedidos;
- a parte que precisa ser usada fora do escritório, como a consulta de estoque pelos vendedores;
- um módulo relativamente isolado, como cadastro de clientes e produtos, que depois serve de base para os outros.

Fechamento financeiro e cálculos fiscais costumam ficar para depois, quando a equipe já conhece bem as regras e a conferência de dados está madura.

Os detalhes técnicos de levar um sistema instalado para o navegador, incluindo atalhos de teclado, impressoras e leitores de código de barras, estão em [como migrar um sistema desktop para a web](https://pervian.tech/blog/migrar-sistema-desktop-para-web).

## Treinamento e convivência dos dois sistemas

Durante a migração por módulos, os dois sistemas vão conviver. Isso precisa de regras claras, não de boa vontade.

- **Um dono por dado.** Cada informação tem um sistema oficial em cada fase. Se os clientes já são cadastrados no sistema novo, o Access passa a recebê-los por sincronização e deixa de permitir edição.
- **Sincronização automática e monitorada.** Enquanto módulos antigos dependem de dados que já mudaram para o sistema novo, uma rotina copia esses dados para o arquivo antigo e avisa quando falha.
- **Data de desligamento por módulo.** Cada parte do Access tem uma data para virar somente leitura. Sem essa data, a convivência vira permanente.
- **Treinamento curto e no posto de trabalho.** Melhor uma sessão por área, com os casos do dia a dia daquela área, do que um treinamento geral para todos.
- **Usuários-chave como multiplicadores.** Uma pessoa por setor acompanha a construção, testa antes dos colegas e vira referência na virada.
- **Período de operação assistida.** Nas primeiras semanas de cada módulo, a equipe técnica fica próxima para corrigir rápido o que aparecer.

Quanto ao prazo, não existe resposta única: depende do tamanho do sistema, da qualidade dos dados e da disponibilidade dos usuários-chave. Um módulo pequeno pode ir ao ar em algumas semanas; um sistema grande inteiro costuma levar meses. Qualquer estimativa séria só sai depois do levantamento.

## Checklist antes de começar

- O arquivo Access ou a planilha tem backup automático e testado (alguém já restaurou um backup para ver se funciona)?
- Existe uma lista das pessoas que usam o sistema e do que cada uma faz nele?
- Alguém da empresa consegue explicar os cálculos mais críticos sem abrir o arquivo?
- As integrações por arquivo (extratos, exportações, importações) estão listadas?
- A área financeira sabe quais números usará para conferir a migração?
- Está definido quem decide quando uma regra antiga deve ser mantida ou mudada?
- Os usuários-chave de cada área terão tempo reservado para o projeto?

Se o backup não está garantido, esse é o primeiro passo, antes de qualquer projeto: copie o arquivo para fora da pasta compartilhada, com rotina diária, em horário em que ninguém esteja com o sistema aberto (uma cópia feita durante gravações pode sair inconsistente), e teste a restauração.

## Erros comuns

- **Reproduzir tudo tela por tela.** A migração é a hora de eliminar relatórios que ninguém usa e simplificar processos, não de copiar defeitos.
- **Mudar tudo ao mesmo tempo.** Trocar o sistema e o processo inteiro na mesma virada multiplica o risco. Primeiro garanta que o novo faz o que o antigo fazia, depois melhore.
- **Ignorar o código VBA porque "é pouca coisa".** Poucas linhas podem conter a regra mais importante do negócio.
- **Desligar o Access cedo demais.** Mantenha o arquivo em modo somente leitura por um período, para consulta e conferência.
- **Deixar a conferência de dados para o final.** Ela deve acontecer a cada carga de teste.

Outros temas de legado, como refatorar ou reescrever e integrar sistemas antigos, estão na categoria [modernização](https://pervian.tech/blog/categoria/modernizacao).

## Perguntas frequentes

### Quanto tempo leva para migrar um sistema Access para a web?

Depende do tamanho do sistema, da qualidade dos dados e da disponibilidade dos usuários-chave. Um módulo pequeno pode ir ao ar em algumas semanas; migrar um sistema Access grande inteiro costuma levar meses. Qualquer estimativa séria só sai depois do levantamento das tabelas, consultas, formulários e código VBA.

### Qual é o limite de tamanho de um banco de dados Access?

Um arquivo Access, no formato .mdb ou .accdb, não passa de 2 GB, somando dados e objetos. Empresas que guardam anos de movimentação ou anexam imagens e PDFs no próprio arquivo chegam perto desse teto e passam a dividir dados em outros arquivos, o que fragmenta a informação e dificulta os relatórios.

### O Access aguenta muitos usuários ao mesmo tempo?

Na prática, não. O Access foi pensado para poucos usuários simultâneos num arquivo compartilhado na rede. Conforme a equipe cresce, aparecem bloqueios de registro, lentidão em horário de pico e mais risco de corrupção do arquivo. No Excel com VBA costuma ser pior, porque em geral só uma pessoa por vez edita a planilha.

### Dá para converter as macros VBA automaticamente para outra linguagem?

Não de forma confiável. As regras de negócio em módulos VBA, eventos de formulário, consultas salvas e macros automáticas precisam ser entendidas e descritas em linguagem de negócio antes de virar código novo. Traduzir o VBA linha a linha costuma copiar defeitos, perder o contexto das regras e manter processos que já não fazem sentido.

### Planilha Excel com VBA também precisa virar sistema web?

Quando a planilha com macros virou sistema crítico, sim. Excel com VBA tem os mesmos riscos de um sistema em Access: regras escondidas em código e fórmulas, edição por uma pessoa de cada vez, pouco controle de acesso e dependência de quem criou o arquivo. O método de migração por módulos, com conferência de dados, é o mesmo.

## Como a Pervian Tech trabalha modernização de Access e VBA

Na Pervian Tech, a modernização de sistemas em Access, Excel com VBA ou FileMaker começa pela leitura do próprio arquivo: catalogamos tabelas, consultas, formulários e código, conversamos com quem usa e devolvemos um inventário de regras em linguagem de negócio, com a ordem de migração recomendada. É trabalho de [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software) antes de ser desenvolvimento, e segue o mesmo método que aplicamos na [modernização de sistemas legados](https://pervian.tech/solucoes/modernizacao-de-sistemas-legados): por módulos, com conferência de dados e convivência controlada.

Cada projeto é sob medida, porque cada sistema guarda regras diferentes. O investimento é definido sob consulta, depois de um diagnóstico inicial gratuito que mostra o tamanho real do que precisa ser migrado. Se a operação da sua empresa depende de um arquivo Access ou de uma planilha com macros, [conte como ele funciona hoje](https://pervian.tech/#contato).