Melhores formas de migrar processos em andamento para um sistema novo

Migrar processos em andamento para um sistema novo pode ser feito de quatro formas — reabrir o processo do zero na plataforma nova, clonar o processo com o histórico anexado como documento de referência e continuar a tramitação a partir da etapa atual, sincronizar os dois sistemas via API durante um período de transição, ou manter o sistema antigo em operação paralela por um prazo definido enquanto o novo assume só o que é protocolado depois da virada. Nenhuma das quatro é “a certa” em abstrato: a escolha depende de quanto histórico cada processo carrega, de quantos estão em andamento no dia da migração e de quanto risco a instituição tolera correr com rastreabilidade durante a troca.

Este guia compara as quatro abordagens pelo critério que mais pesa numa troca de sistema em pleno funcionamento: o que acontece com o processo que já está tramitando há meses — às vezes anos — quando a plataforma muda debaixo dele, sem que o requerente perceba interrupção nem o órgão perca o que já foi decidido até ali.

O que muda entre as abordagens

Abordagem	Preserva histórico pesquisável	Reinicia prazo	Esforço técnico	Risco de processo órfão
Reabrir do zero	Não	Sim	Baixo	Alto
Clone com histórico anexado	Parcial (fica em anexo)	Não	Médio	Baixo
Sincronização via API	Sim, nativamente	Não	Alto	Baixo, se bem testada
Operação paralela por prazo definido	Sim, no sistema antigo	Não	Médio	Médio, por dois lugares de busca

A diferença real entre elas não é técnica no sentido de “qual é mais moderna” — é sobre onde fica a responsabilidade por um prazo em curso, uma assinatura já coletada ou um despacho que fundamentou uma decisão, enquanto a virada de sistema acontece. Reabrir do zero empurra esse risco para o requerente e para quem for auditar depois; as outras três distribuem esse risco de formas diferentes entre esforço técnico e tempo de transição.

Reabrir o processo do zero no sistema novo

É a abordagem mais rápida de implantar e a mais usada quando o volume de processos em andamento é pequeno, quando o sistema anterior é uma planilha sem estrutura de dado confiável, ou quando não sobrou tempo de projeto para nenhuma outra alternativa. O custo aparece depois: reiniciar a contagem de um prazo que já estava em curso — de resposta ao requerente, de recurso, de prescrição — cria risco jurídico real, porque o prazo original não deixou de correr só porque o sistema mudou. E o requerente perde acesso ao histórico de decisões já tomadas sobre o próprio pedido, o que costuma gerar reclamação e retrabalho de atendimento logo nas primeiras semanas depois da virada.

Clonar o processo com o histórico anexado e continuar a tramitação

É o caminho mais comum quando uma prefeitura troca de sistema de licenciamento ou de protocolo com processos ativos em curso: abrir o processo já na etapa em que ele se encontra, anexar o consolidado do histórico anterior — normalmente um PDF — como documento de referência, e seguir a tramitação dali em diante dentro do fluxo novo. Preserva rastreabilidade suficiente para sustentar uma auditoria e não reinicia prazo, mas o histórico anterior vira um anexo estático: não é pesquisável campo a campo, e localizar um despacho específico de dois anos atrás significa abrir o PDF e procurar manualmente, não filtrar pelo sistema.

Sincronizar via API durante a transição

Faz sentido para instituições com volume alto de processos em andamento e um sistema legado que já expõe alguma interface de integração — mesmo que limitada. Em vez de exportar processo por processo, os dois sistemas trocam dado estruturado automaticamente durante o período de transição, o que reduz erro de digitação e permite migrar em lotes, não tudo de uma vez. A limitação não é da abordagem, é da realidade de boa parte dos sistemas legados do setor público: planilha e sistema fechado sem nenhuma API disponível simplesmente não oferecem essa porta, e forçar uma integração ali custa mais caro do que as outras três opções.

Manter operação paralela por prazo definido

O sistema antigo continua ativo só para consulta e conclusão dos processos que já estavam abertos; tudo que é protocolado depois da virada nasce direto na plataforma nova. Reduz o risco de perder dado no meio da transição, porque nada precisa ser migrado sob pressão, mas cria dois lugares de busca enquanto o prazo não se encerra — quem precisa de uma visão consolidada de quantos processos estão em andamento no órgão não encontra essa resposta em nenhum dos dois sistemas isoladamente, só na soma manual dos dois.

O que a legislação exige

A Lei Geral de Proteção de Dados (Lei nº 13.709/2018) trata a integridade e a segurança do dado pessoal como responsabilidade do controlador em qualquer etapa do tratamento — o que inclui o momento em que um processo com dado de requerente, CPF ou CNPJ é transferido de um sistema para outro, não apenas o armazenamento em regime normal. Já a Lei do Governo Digital (Lei nº 14.129/2021) trata a interoperabilidade entre sistemas de governo como diretriz da administração pública, o que reforça que uma migração planejada — com dado estruturado trafegando entre sistemas de forma rastreável — está mais alinhada ao espírito da lei do que reabrir cada processo do zero por falta de integração.

Critérios para escolher

Considere o volume de processos em andamento no dia da virada: poucos processos toleram o esforço manual do clone com anexo; centenas ou milhares justificam investir em sincronização via API. Avalie a criticidade jurídica de cada tipo de processo — um processo com prazo decadencial ou prescricional em curso não pode simplesmente reiniciar a contagem, o que já elimina reabrir do zero como opção segura nesse caso. Verifique se o sistema legado expõe alguma interface de integração antes de planejar a sincronização via API — sem isso, a abordagem não é viável, por melhor que pareça no papel. E defina, desde o início, um prazo de encerramento para qualquer operação paralela: mantê-la em aberto indefinidamente é o que transforma uma medida de transição em um segundo sistema permanente.

Como o Aprova se encaixa

• Permite abrir o processo diretamente na etapa em que ele estava no sistema anterior, com o histórico anexado como documento de referência dentro do próprio processo, sem reiniciar prazo nem numeração.
• Integração via API com o sistema legado durante o período de transição, trazendo dado estruturado em lotes, sem depender de migrar todo o estoque de uma vez.
• Numeração compatível com o processo migrado, combinando a referência do sistema antigo com a sequência do novo, para que o requerente continue localizando o próprio pedido pelo número que já conhecia.
• Histórico completo de cada ação — despacho, assinatura, encaminhamento — registrado a partir da migração, com data e autor, sustentando auditoria mesmo quando parte do histórico anterior segue apenas como anexo.

FAQ sobre migração de processos em andamento

É possível migrar só os processos em andamento e deixar os concluídos no sistema antigo?

Sim, e costuma ser a decisão mais eficiente: processo concluído raramente precisa continuar tramitando, só ser consultado — o que o sistema antigo, mantido como repositório de consulta, já resolve sem exigir migração completa.

Migrar de sistema reinicia o prazo de resposta ao requerente?

Não deveria. O prazo já em curso continua contando a partir do marco original; reiniciá-lo por causa da troca de sistema é uma decisão que, sem base legal ou normativa local, pode ser questionada pelo requerente ou por um órgão de controle.

O que fazer quando o sistema legado não tem nenhuma interface de integração?

Nesses casos, a sincronização via API deixa de ser viável e a escolha realista fica entre o clone com histórico anexado e a operação paralela por prazo definido — a decisão passa a depender mais do volume de processos do que da tecnologia disponível.

Quanto tempo leva para decidir quais processos migram e quais ficam só como consulta?

Depende do volume total, mas o levantamento em si — listar o que está em andamento, o que está concluído e o que tem prazo crítico em curso — deveria acontecer antes de escolher a abordagem, não depois, para evitar decisão tomada sob pressão do cronograma de desligamento do contrato antigo.

É preciso manter o sistema antigo disponível depois que a migração termina?

Normalmente sim, por um período de retenção compatível com a tabela de temporalidade documental aplicável àquele tipo de processo — mesmo depois que nenhum processo mais depende dele para tramitar, pode haver obrigação de manter o histórico consultável.

Conclusão

Não existe uma abordagem certa para toda troca de sistema — existe a abordagem certa para o volume de processos em andamento, a criticidade jurídica de cada um e o tempo real disponível até o contrato antigo se encerrar. O erro mais caro não é escolher a abordagem “errada” entre as quatro: é decidir sob pressão, sem levantar antes quantos processos carregam prazo em curso, e descobrir depois que um requerente perdeu o histórico da própria solicitação no meio da transição. Para ver como estruturar a migração de processos em andamento dentro do processo administrativo eletrônico da sua instituição, agende uma demonstração da Aprova ou conheça o processo eletrônico da Aprova.