Como migrar processos de um sistema legado sem perder a tramitação

Migrar processos de um sistema legado sem perder a tramitação significa transportar cada processo em andamento para a nova plataforma preservando seu histórico, vinculando o requerente original e permitindo que ele continue de onde parou — em vez de exigir que ele abra um novo requerimento do zero. A técnica mais usada é gerar um espelho (clone) do processo antigo dentro do novo sistema: esse espelho herda os dados já preenchidos e assume a tramitação ativa a partir daquele ponto, enquanto o sistema anterior permanece disponível apenas para consulta durante um período de transição com prazo definido.

Este guia cobre o que decidir antes de migrar dado a dado, como estruturar a continuidade de tramitação sem duplicar o número de processo, como lidar com integrações que dependem do sistema legado (como geração de boleto) e quais indicadores mostram que já é seguro desligar o sistema anterior.

O que é migração de processos entre sistemas

Migração de processos é o conjunto de decisões e rotinas técnicas que transportam processos administrativos de um sistema para outro sem perder informação, vínculo com o requerente ou histórico de tramitação. Existem dois níveis distintos de migração, e confundi-los é a causa mais comum de retrabalho:

• Migração de consulta. O processo antigo é importado como um registro estático — útil para auditoria e histórico, mas sem possibilidade de receber novos despachos. Serve para processos já encerrados.
• Migração com continuidade de tramitação. O sistema novo cria um espelho do processo, vincula o requerente externo a esse espelho e permite que a tramitação continue normalmente a partir do ponto em que parou no sistema anterior — sem que o requerente precise protocolar de novo.

A maioria dos órgãos precisa das duas ao mesmo tempo: processos encerrados entram como consulta, processos em aberto entram com continuidade.

Por que a migração mal planejada trava a tramitação

Quando a migração não é desenhada com essa distinção, alguns problemas recorrentes aparecem:

• Dois sistemas rodando em paralelo sem comunicação. Cada processo que já flutua por várias secretarias continua exigindo que o servidor alimente informação em dois lugares — o que dobra o trabalho manual em vez de reduzi-lo.
• Dependência de terceiros para dados críticos. Se a geração de boleto ou outra rotina fica no sistema legado, a migração de processos não resolve sozinha esse gargalo: depende do fornecedor anterior disponibilizar backup de dados e, quando aplicável, uma integração de API para manter a automação.
• Requerente perdendo o vínculo com o próprio processo. Sem a etapa de vincular o requerente externo ao espelho migrado, ele fica sem visibilidade sobre uma solicitação que já existia — e a prefeitura volta a receber contato manual perguntando “onde está meu processo”.

Passo a passo para migrar processos sem perder a tramitação

1. Levante o volume e o status de cada processo aberto no sistema legado

Antes de negociar qualquer prazo de corte, separe os processos por status: em tramitação, aguardando retorno do requerente, e encerrados. Esse levantamento define o volume real de migração com continuidade — normalmente uma fração bem menor que o total de registros históricos.

2. Obtenha o backup ou a exportação de dados do sistema anterior

A migração depende do fornecedor do sistema legado disponibilizar o backup dos processos. Sem esse dado, não há como gerar o espelho — a prefeitura fica limitada a recadastrar manualmente cada processo em aberto, o que deve ser evitado sempre que o volume justificar negociação de exportação.

3. Defina o que migra como consulta e o que migra com continuidade

Aplique a distinção da seção anterior: processos encerrados viram registro de consulta; processos em aberto recebem o tratamento de espelho com continuidade de tramitação. Documente esse critério antes de rodar a migração — não deixe a decisão para o momento da execução.

4. Gere o espelho do processo e vincule o requerente externo a ele

O processo migrado precisa nascer já vinculado ao requerente que abriu a solicitação original, para que ele continue acompanhando pelo mesmo login, sem precisar protocolar de novo. Esse é o ponto onde mais projetos de migração falham silenciosamente: o dado migra, mas o vínculo com a pessoa não.

5. Configure a integração de geração de boleto, se o sistema legado disponibilizar

Quando a arrecadação depende de um sistema tributário próprio, verifique se ele oferece integração via API para gerar boletos automaticamente a partir do novo sistema. Se não oferecer, planeje uma rotina manual temporária — e comunique isso à equipe antes do corte, para não gerar frustração no primeiro vencimento.

6. Rode um período de operação em paralelo com data de corte definida

Durante a transição, mantenha o sistema legado acessível apenas para consulta e finalização dos processos que ainda dependem dele — nunca para abertura de processo novo. Fixe uma data de corte explícita; período de paralelismo sem prazo tende a se estender indefinidamente e dobra o esforço operacional.

7. Audite a integridade dos dados migrados antes de desativar o sistema legado

Confirme, por amostragem, que os processos migrados mantiveram anexos, despachos e vínculo com o requerente corretos. Só depois dessa auditoria — não antes — encerre o acesso ao sistema anterior.

O que a legislação exige

A Lei nº 14.129/2021 (Lei do Governo Digital) trata a interoperabilidade entre sistemas públicos como diretriz central da transformação digital dos serviços — o que dá amparo direto ao planejamento de migração entre sistemas sem descontinuidade do atendimento ao cidadão. Quando a migração envolve dados pessoais do requerente trafegando entre sistemas — nome, CPF, documentos anexados —, aplica-se a Lei nº 13.709/2018 (LGPD), cujo art. 6º exige que o tratamento observe finalidade e necessidade, e cujo art. 46 exige medidas técnicas de segurança durante a transmissão de dados entre sistemas — o que inclui expressamente a etapa de exportação e importação na migração.

Como o Aprova resolve isso

• Migração de processos com geração de um espelho do registro original, preservando o histórico do sistema anterior para consulta sem duplicar o número de processo.
• Continuidade de tramitação a partir do ponto em que o processo parou, com o requerente externo vinculado automaticamente ao processo migrado — sem exigir novo protocolo.
• Central de despachos que concentra toda a movimentação em ordem cronológica, inclusive a etapa herdada do sistema anterior, mantendo a rastreabilidade completa em uma única tela.
• Integração via API aberta com sistemas de terceiros, incluindo geração automática de boleto quando o sistema legado disponibiliza essa interoperabilidade.
• Trilha de auditoria com registro de quem abriu, quem visualizou e quando, válida desde o momento da migração — o que sustenta qualquer contestação futura sobre prazo ou ciência do requerente.

Indicadores para medir a migração

• Percentual de processos em aberto migrados com continuidade de tramitação (não apenas como consulta).
• Tempo médio do período de operação em paralelo entre os dois sistemas, do início até o corte definitivo.
• Número de processos com inconsistência identificada na auditoria pós-migração (anexo, despacho ou vínculo de requerente).
• Volume de acessos ao sistema legado após a data de corte — deve tender a zero, exceto para consulta histórica.
• Percentual de boletos gerados automaticamente via integração, versus gerados manualmente durante a transição.

FAQ sobre migração de processos entre sistemas

O requerente precisa abrir um novo processo depois da migração?

Não, quando a migração inclui a etapa de continuidade de tramitação: o requerente é vinculado ao processo migrado e continua acompanhando pelo mesmo processo, a partir de onde ele parou no sistema anterior.

É possível migrar só os processos em aberto e deixar o histórico encerrado no sistema antigo?

Sim, e essa costuma ser a estratégia mais eficiente: processos encerrados raramente precisam de continuidade, apenas de consulta ocasional para auditoria, o que reduz bastante o volume de migração com prioridade alta.

O que acontece se o sistema legado não disponibilizar backup dos dados?

Sem o backup, a migração automática não é possível para aquele volume de processos — a alternativa é recadastro manual, e o órgão deve avaliar o custo desse recadastro antes de assumir prazo de corte com a nova plataforma.

Quanto tempo deve durar o período de operação em paralelo?

Não existe prazo único — depende do volume de processos em aberto e da complexidade de integrações pendentes, como geração de boleto. O essencial é fixar uma data de corte explícita desde o início, para que o paralelismo não vire operação permanente.

A migração de dados pessoais exige algum cuidado adicional de conformidade?

Exige. Como a migração envolve tratamento de dados pessoais do requerente, aplicam-se as exigências da LGPD sobre finalidade, necessidade e segurança na transmissão entre sistemas — o que deve ser considerado desde o desenho técnico da migração, não como etapa posterior.

Conclusão

Migrar processos de um sistema legado sem perder a tramitação é uma decisão de arquitetura, não uma exportação simples de planilha: exige separar o que precisa de continuidade do que precisa apenas de consulta, vincular corretamente o requerente ao processo migrado e fixar um prazo de corte para o período de operação em paralelo. Órgãos que já avançaram na digitalização do protocolo administrativo sabem que a etapa de migração costuma ser o maior risco de descontinuidade percebida pelo cidadão — e também processos digitais na gestão pública reforça que tramitação sem papel só funciona quando a transição entre sistemas preserva o vínculo do requerente com sua própria solicitação.

Se a sua prefeitura está avaliando a troca de sistema e precisa migrar processos em aberto sem gerar retrabalho para o requerente, agende uma demonstração e veja como estruturar essa transição com continuidade real de tramitação.