A migração para a Primavera raramente é um problema de software. É um problema de dados, de calendário e de responsabilidades. Quem quer passar à Primavera a partir de folhas de Excel, de um programa de contabilidade que já não chega ou de um ERP antigo deve tratar a migração como um subprojeto com objetivos, testes e critérios de aceitação próprios. O mesmo vale para a migração entre versões da Primavera, que parece mais simples, mas esconde armadilhas nas personalizações e nas integrações.
Esta página explica como conduzir uma migração para a Primavera numa empresa portuguesa: de onde partem os dados, o que levar, como fazer a bascule, o que testar e como voltar atrás se for preciso.
Que tipo de migração tem em mãos?
Antes de falar de ferramentas, identifique o ponto de partida. Cada origem tem os seus riscos.
| Origem | O que costuma correr bem | O que costuma correr mal |
|---|---|---|
| Folhas de Excel | Estrutura simples, poucos módulos | Dados duplicados, códigos inconsistentes, regras que só uma pessoa conhece |
| Programa de contabilidade | Plano de contas e terceiros já organizados | Ausência de stocks, de gestão comercial e de rastreabilidade de documentos |
| ERP antigo | Muita informação histórica e processos rodados | Modelos de dados incompatíveis, personalizações sem documentação |
| Outra versão da Primavera | Modelo de dados familiar | Extensões e integrações que deixam de funcionar |
A partir desta leitura, decide-se se a migração é uma simples carga de dados, uma reconstrução parcial ou uma oportunidade de redesenhar processos. Se ainda está a comparar soluções antes de se comprometer, a nossa página sobre alternativas à Primavera ajuda a confirmar a escolha.
Migrar de Excel, de contabilidade ou de um ERP antigo
Excel: o risco está no que não está escrito
Uma empresa que funciona em folhas de cálculo tem, na prática, um sistema de informação, só que sem regras impostas. Antes de migrar, é preciso descobrir as regras implícitas: como se calculam os preços, quem aprova descontos, como se trata uma devolução. Essas regras terão de ser traduzidas em parametrizações da Primavera. A migração de Excel é, por isso, mais um trabalho de análise do que de importação.
Programa de contabilidade: ganhar a gestão comercial
Quando o ponto de partida é um programa de contabilidade, o plano de contas e os terceiros costumam estar em bom estado. O desafio é acrescentar o que faltava: vendas, compras, stocks, tesouraria. Convém definir com o contabilista certificado a data de corte e a forma de transportar os saldos de abertura, para que a contabilidade fique coerente de um sistema para o outro.
ERP antigo: não copiar os defeitos
Num ERP antigo, a tentação é reproduzir tudo igual. É um erro frequente: as personalizações acumuladas ao longo dos anos refletem muitas vezes limitações do sistema anterior, não necessidades reais. Aproveite a migração para perguntar, processo a processo, se a regra ainda faz sentido. Se há dúvidas sobre o estado de um projeto anterior, uma auditoria e recuperação de projeto Primavera pode servir de ponto de partida.
Migração entre versões da Primavera
Mudar de versão dentro da Primavera não obriga a reconstruir os dados, mas obriga a verificar tudo o que se apoia neles: relatórios, ligações a outras aplicações, extensões desenvolvidas à medida. Antes de decidir, consulte a página sobre versões e edições da Primavera para perceber o que muda de uma edição para outra.
No modelo cloud, o fabricante afirma que o sistema é atualizado de forma permanente e que o utilizador trabalha sempre na última versão, sem avarias nem interrupções operacionais. Esta promessa retira a pressão das grandes mudanças de versão, mas não elimina o trabalho do lado da empresa: as integrações e as personalizações têm de continuar compatíveis com um sistema que evolui sem pausas. O fabricante apresenta ainda as suas soluções ERP como garantindo uma atualização automática permanente face às evoluções tecnológicas, fiscais e legais, o que é relevante para quem tem de acompanhar a evolução do SAF-T (PT) e da faturação certificada. Para comparar este cenário com um servidor próprio, veja o alojamento cloud da Primavera.
Que dados migrar, e que dados deixar para trás?
Esta é a decisão que mais condiciona o prazo e o custo do projeto. Uma regra útil: migre o que serve para trabalhar amanhã, arquive o que serve para consultar.
Dados mestres
- Clientes e fornecedores, com NIF validado e moradas completas.
- Artigos, famílias, unidades e preços em vigor.
- Plano de contas, centros de custo e tabelas de IVA.
- Colaboradores e estrutura organizativa, se a gestão de pessoal passar para o novo sistema.
Saldos e documentos em aberto
Os saldos de abertura de contabilidade, as contas correntes de clientes e fornecedores, as encomendas pendentes e o stock valorizado são, em regra, indispensáveis. Devem ser reconciliados com a contabilidade na data de corte: uma diferença de arranque contamina todos os meses seguintes.
Histórico
O histórico completo raramente compensa. Migrar anos de documentos obriga a mapear campos que não existem no destino e aumenta o risco de erros. Em alternativa, mantenha o sistema anterior em modo de consulta, ou exporte os documentos para um arquivo pesquisável. Respeite sempre os prazos legais de conservação de documentos fiscais e contabilísticos, a confirmar com o contabilista certificado.
Limpeza dos dados: o trabalho que ninguém quer fazer
A qualidade da migração depende do que se faz antes da carga. A limpeza compreende, no mínimo:
- remover duplicados de clientes, fornecedores e artigos;
- uniformizar códigos, designações e unidades de medida;
- corrigir NIF, moradas e códigos postais inválidos;
- desativar o que já não se usa;
- decidir quem é o responsável de cada conjunto de dados.
Este trabalho não pode ser delegado inteiramente ao integrador. Só a empresa sabe que cliente está inativo ou que artigo foi descontinuado. Se a equipa ainda não tem competências para o fazer, a formação em Primavera deve começar antes da bascule, não depois.
Estratégia de bascule: grande explosão ou arranque faseado?
Há duas abordagens principais.
| Abordagem | Quando faz sentido | Risco principal |
|---|---|---|
| Bascule única | Empresa pequena, poucos módulos, período calmo | Qualquer falha afeta tudo ao mesmo tempo |
| Arranque faseado | Vários módulos ou várias unidades | Convivência temporária entre dois sistemas |
Na bascule única, o corte faz-se numa data precisa, normalmente no fim de um período contabilístico, para facilitar os saldos de abertura. No arranque faseado, arranca-se por módulo (por exemplo, contabilidade e depois vendas e stocks) ou por unidade. Exige interfaces temporárias e disciplina, mas limita o impacto de um problema.
Seja qual for a escolha, três pontos são inegociáveis no contexto português:
- a série de documentos do novo programa de faturação certificado deve estar criada e comunicada à Autoridade Tributária antes do primeiro documento emitido;
- o ATCUD e o código QR devem aparecer corretamente nos documentos desde o primeiro dia;
- o ficheiro SAF-T (PT) deve ser testado, com os dois sistemas e com o período de transição, antes de ser exigido.
Para os requisitos de fundo, consulte o guia sobre SAF-T (PT) e ERP e o de software de faturação certificado.
Testes: o que validar antes de mudar
Uma migração sem testes é uma aposta. O ensaio deve ser feito com dados reais, numa cópia, e repetido até o resultado ser estável.
Ensaios de carga
Faça pelo menos uma carga completa de ensaio, comparando totais: número de clientes, valor de stock, saldos por conta, contas correntes. Se os totais não batem, não se avança.
Testes de processo
Percorra os processos reais de ponta a ponta: orçamento, encomenda, guia, fatura, recebimento, compra, entrada em armazém, pagamento, fecho do mês. É aqui que se descobrem parametrizações em falta.
Testes de integração
Verifique todas as ligações a outras aplicações: loja online, banca, ponto de venda, ferramentas de relatórios. A página sobre integrações da Primavera ajuda a inventariar o que tem de ser reconfigurado.
Aceitação pelos utilizadores
Cada responsável de área deve validar, por escrito, o que lhe diz respeito. A aceitação deve ser feita por quem vai usar o sistema, não só por quem o instalou.
Plano de retorno: sair de um corte falhado
Um plano de retorno define, antes da bascule, em que condições se volta ao sistema anterior e como. Inclui:
- uma cópia completa e verificada do sistema anterior, tirada imediatamente antes do corte;
- o sistema anterior mantido operacional, sem alterações, durante o período de validação;
- critérios de aceitação objetivos (totais reconciliados, documentos emitidos corretamente, fecho técnico concluído);
- um responsável com autoridade para decidir o retorno;
- uma regra para recuperar os movimentos feitos entretanto no novo sistema.
Convém também decidir o que acontece com os documentos já emitidos no novo programa se se voltar atrás: a faturação certificada não tolera improvisos, e o contabilista certificado deve estar envolvido nesta decisão.
Erros a evitar numa migração para a Primavera
- Migrar sem limpar. Os dados maus ficam mais difíceis de corrigir depois da carga.
- Querer tudo no primeiro dia. Um âmbito demasiado vasto adia o arranque; priorize o essencial.
- Escolher a data de corte sem consultar a contabilidade. Uma bascule a meio de um período complica saldos e declarações.
- Esquecer as integrações. São a causa mais comum de paragens após o arranque.
- Não formar a equipa a tempo. Um sistema novo com utilizadores inseguros produz documentos errados.
- Saltar o plano de retorno. Só parece desnecessário até ser preciso.
- Entregar tudo ao fornecedor. O dono do negócio deve ser o dono dos dados e das decisões.
Estes erros são os mesmos que aparecem em muitos projetos falhados; o guia sobre erros em projetos de ERP desenvolve-os com mais detalhe.
Quem deve conduzir a migração?
Uma migração bem-sucedida junta três papéis: a empresa, que decide e valida; o contabilista certificado, que garante a coerência fiscal; e o integrador, que parametriza, carrega e testa. O fabricante apresenta o seu portefeuil (Primavera, Eticadata, Ekon, entre outras marcas) com mais de trinta anos de experiência nos mercados português, espanhol e dos países africanos lusófonos; esta experiência, porém, não substitui a preparação do projeto do lado do cliente nem a escolha de um integrador adequado ao seu contexto.
Para escolher bem, veja como escolher um parceiro Primavera e como funciona a nossa mise en relation gratuita. Não somos afiliados a nenhum fabricante nem a nenhum integrador: descrevemos o seu projeto e encaminhamo-lo para um profissional que pode assumir a migração.
Por onde começar
Comece por um inventário curto: de onde vêm os dados, quem os mantém, que processos dependem deles, que integrações existem e que obrigações fiscais estão em jogo. Com esse inventário, qualquer integrador consegue dizer se a migração é uma simples carga de dados ou um projeto de reconstrução, e propor um plano de bascule, de testes e de retorno adaptado à sua empresa. Se pretende ir mais longe, a página sobre a implementação da Primavera descreve o projeto completo em que a migração se insere.
Perguntas frequentes
Qual é a diferença entre migrar para a Primavera e atualizar a Primavera?
Migrar para a Primavera significa mudar de sistema: os dados saem de Excel, de um programa de contabilidade ou de outro ERP e são reconstruídos num modelo diferente. Atualizar é passar de uma versão da Primavera para outra, mantendo o mesmo modelo de dados. O segundo caso é, em regra, mais curto, mas continua a exigir testes e cópia de segurança.
Que dados devo levar para a Primavera?
Leve os dados mestres úteis (clientes, fornecedores, artigos, plano de contas), os saldos de abertura e os documentos em aberto. O histórico detalhado só se justifica se alguém o consulta ou se uma obrigação legal o exige; caso contrário, arquive-o em consulta no sistema anterior. Quanto menos lixo migrar, mais fiável fica o arranque.
É possível migrar sem interromper a faturação?
Sim, desde que a bascule seja planeada num período de menor atividade e que a data de corte esteja definida com o contabilista certificado. A faturação deve passar para o novo programa certificado numa série própria, evitando misturar documentos dos dois sistemas na mesma série. O ensaio prévio com dados reais reduz o risco de paragem.
O que acontece se a migração correr mal?
É para isso que existe o plano de retorno: o sistema anterior fica intacto e disponível até a validação final, com uma cópia completa dos dados antes do corte. Se um critério de aceitação falhar, volta-se ao sistema antigo e corrige-se antes de nova tentativa. Sem este plano, um erro de bascule pode bloquear a empresa.
A migração para a Primavera na cloud é diferente?
O trabalho sobre os dados é o mesmo, mas a cloud simplifica as versões: segundo o fabricante, o sistema é atualizado de forma permanente e o utilizador trabalha sempre na última versão. Em contrapartida, a gestão do ambiente, das ligações e das integrações passa a fazer parte do projeto e deve ser acordada com o integrador.
Fontes
Os nomes de software mencionados são marcas dos respetivos editores, citadas a título meramente informativo. Este site é independente e não é afiliado a nenhum editor.