Capítulo 49 — Migração e Transição Operacional

49.1 Objetivo do Capítulo

Este capítulo descreve as estratégias, processos e controles que governam a transição de órgãos participantes para a Plataforma de Relacionamento Digital com o Cidadão — cobrindo a incorporação de dados históricos, a coexistência de processos durante a transição, a validação de integridade e completude, e o encerramento controlado de operações anteriores.

A transição operacional é distinta do onboarding de tenant (Capítulo 48): o onboarding provisiona e configura o ambiente técnico do tenant. A transição trata da absorção de volume, dados e fluxos operacionais reais que o órgão já possui — o que exige planejamento estruturado, ferramentas de carga de dados, validação rigorosa e planos de reversão.

49.2 Definição e Escopo

A transição operacional abrange:

• Carga de dados históricos: importar registros de cidadãos, solicitações, documentos, histórico de atendimentos e outros dados que o órgão deseja trazer para a plataforma;
• Coexistência de processos: período em que o órgão opera parcialmente na plataforma e parcialmente em fluxos anteriores, com sincronização controlada;
• Corte operacional (cutover): momento em que a plataforma passa a ser o sistema de registro oficial para o escopo pactuado;
• Validação pós-transição: verificação de que dados foram transferidos com integridade e de que a operação está estável;
• Encerramento de operações paralelas: desativação ordenada dos fluxos que foram substituídos pela plataforma.

O escopo de cada transição é definido no Plano de Transição específico do órgão, elaborado antes do início da carga.

49.3 Princípios da Transição

1. Nenhum dado perdido — a transição não admite perda de dados históricos dentro do escopo pactuado; toda carga é verificada por contagem e reconciliação;
2. Integridade como critério de avanço — cada fase da transição só avança quando a anterior está validada; não há avanço por prazo sem validação;
3. Reversibilidade até o cutover — até o momento de corte operacional, o plano de reversão está disponível e testado;
4. Operação paralela limitada — a coexistência de processos é tolerada por período definido; não é estado permanente;
5. Dados de transição separados de produção — cargas são executadas em ambiente de staging ou em janela controlada em produção, nunca misturadas com operação em tempo real sem validação;
6. Traçabilidade de origem — cada dado carregado registra sua origem, o método de carga e o responsável pela validação;
7. Comunicação estruturada — cidadãos, usuários internos e gestores são informados sobre o cronograma e o impacto da transição com antecedência definida.

49.4 Papéis e Responsabilidades

49.5 Fases da Transição Operacional

FASE 1: PLANEJAMENTO
  Levantamento de dados, mapeamento, Plano de Transição

FASE 2: PREPARAÇÃO
  Extração, transformação, validação de qualidade, staging

FASE 3: CARGA PILOTO
  Subconjunto de dados em staging, reconciliação, ajustes

FASE 4: CARGA COMPLETA
  Todos os dados em produção (janela controlada)

FASE 5: VALIDAÇÃO PÓS-CARGA
  Reconciliação, testes de integridade, aceite do órgão

FASE 6: OPERAÇÃO PARALELA (se aplicável)
  Plataforma e processo anterior operam simultaneamente

FASE 7: CUTOVER
  Corte para plataforma como sistema de registro oficial

FASE 8: ENCERRAMENTO
  Desativação de operações paralelas, arquivamento

49.6 Fase 1 — Planejamento

49.6.1 Levantamento de Dados

O levantamento identifica:

• quais conjuntos de dados serão carregados (cidadãos, solicitações, documentos, histórico de atendimentos, processos, etc.);
• o volume estimado por conjunto;
• o formato atual dos dados de origem;
• regras de negócio específicas que determinam o mapeamento;
• dados que não serão carregados e o motivo (fora de escopo, irrelevantes, não localizáveis);
• dados que serão carregados parcialmente e a política de corte temporal.

49.6.2 Plano de Transição

O Plano de Transição é um documento formal, aprovado pelo Gestor de Transição do Órgão e pelo Gestor de Produto, contendo:

• escopo de dados e funcionalidades na transição;
• cronograma com datas, responsáveis e critérios de avanço por fase;
• regras de mapeamento de dados;
• critérios de qualidade e thresholds de aceitação;
• plano de comunicação (quem, quando e como é informado);
• plano de reversão com critérios de ativação;
• critérios de aceite do cutover.

49.6.3 Análise de Risco da Transição

Riscos específicos da transição são identificados e mitigados no planejamento:

49.7 Fase 2 — Preparação

49.7.1 Extração e Transformação

Os dados de origem são extraídos, transformados e preparados para carga:

Dados de Origem
    │
Extração (formato original)
    │
Limpeza (deduplicação, trim, normalização de encoding)
    │
Transformação (mapeamento para modelo da plataforma)
    │
Enriquecimento (dados complementares quando necessário)
    │
Validação de Qualidade (pré-carga)
    │
Arquivo de Carga (formato de importação)

49.7.2 Regras de Mapeamento

Cada campo de origem é mapeado para o campo correspondente na plataforma:

Exemplo — Mapeamento de Cidadão:

Origem           Plataforma               Transformação
─────────────────────────────────────────────────────────
NM_PESSOA        citizen.name             string, trim
NR_CPF           citizen.cpf              remover pontuação
DT_NASCIMENTO    citizen.birthDate        converter DD/MM/YYYY → YYYY-MM-DD
NR_TELEFONE      citizen.phone            normalizar para E.164
DS_EMAIL         citizen.email            lowercase
NM_LOGRADOURO    citizen.address.street   string

49.7.3 Validação Pré-Carga

Antes da carga, o arquivo é validado:

• contagem de registros vs. origem declarada;
• ausência de campos obrigatórios;
• formatos inválidos (CPF inválido, e-mail malformado, data incoerente);
• duplicatas dentro do arquivo de carga;
• valores fora dos domínios aceitos.

A validação gera relatório com: total de registros válidos, inválidos por regra, alertas e bloqueadores. A carga não avança com bloqueadores acima do threshold de aceite.

49.8 Fase 3 — Carga Piloto

49.8.1 Subconjunto Representativo

A carga piloto processa um subconjunto representativo — tipicamente 5% do volume total ou um conjunto de dados de uma unidade específica — em ambiente de staging. O objetivo é validar o pipeline de carga antes de aplicar ao volume completo.

49.8.2 Execução

Arquivo de Carga (piloto)
    │
Migration Service (escrito pela Parceira)
    │
  Valida cada registro (regras de negócio da plataforma)
    │
  Carrega via API interna ou inserção direta (conforme estratégia)
    │
  Registra resultado por registro: LOADED, SKIPPED, FAILED
    │
Relatório de Carga Piloto
    │
Reconciliação com origem
    │
Aprovação para fase completa ou ajuste do pipeline

49.8.3 Reconciliação

A reconciliação compara:

• quantidade de registros na origem vs. na plataforma após carga;
• amostra de registros com campos críticos verificados manualmente pelo Data Steward;
• integridade referencial (ex.: solicitações com cidadão existente na plataforma);
• dados com LGPD verificados por amostragem.

49.9 Fase 4 — Carga Completa

49.9.1 Janela de Carga

A carga completa é executada em janela de manutenção fora do horário de pico operacional. A janela é comunicada ao órgão com antecedência mínima de 5 dias úteis.

49.9.2 Sequência de Carga

A ordem de carga respeita dependências entre entidades:

1. Cidadãos (sem dependência)
   │
2. Endereços e contatos (dependem de Cidadão)
   │
3. Documentos de identidade (dependem de Cidadão)
   │
4. Solicitações históricas (dependem de Cidadão + Serviço)
   │
5. Documentos de solicitação (dependem de Solicitação)
   │
6. Histórico de atendimentos (dependem de Cidadão)
   │
7. Manifestações de ouvidoria (dependem de Cidadão)

49.9.3 Carga Incremental e Idempotência

Scripts de carga são idempotentes: executar a carga duas vezes não duplica registros. Cada registro carregado possui:

• identificador externo de origem (para deduplicação em reexecuções);
• status de carga (LOADED, SKIPPED, FAILED);
• timestamp de carga;
• responsável pela execução.

Se a janela de carga é interrompida por falha, a carga retoma do ponto de interrupção sem reprocessar registros já carregados.

49.9.4 Monitoramento Durante a Carga

O Platform Team monitora em tempo real:

• taxa de carga (registros/minuto);
• taxa de falhas;
• uso de recursos do banco (CPU, IOPS, connections);
• impacto em outros tenants (isolamento verificado);
• progresso vs. estimativa (tempo restante).

49.10 Fase 5 — Validação Pós-Carga

49.10.1 Relatório de Carga

Ao concluir a carga completa, o Migration Service gera relatório formal:

49.10.2 Critérios de Aceite

A transição só avança para a fase de cutover quando todos os critérios de aceite são atendidos:

• taxa de sucesso de carga ≥ threshold definido (tipicamente 99,5%);
• reconciliação manual pelo Data Steward aprovada;
• zero registros com dados pessoais carregados incorretamente;
• testes funcionais com dados reais bem-sucedidos;
• plano de reversão testado e confirmado viável.

A aprovação formal é registrada como aceite do Gestor de Transição do Órgão.

49.11 Fase 6 — Operação Paralela (Quando Aplicável)

49.11.1 Definição e Escopo

A operação paralela é o período em que o órgão opera simultaneamente na plataforma e em processos anteriores para o mesmo escopo. Ela é prevista quando o corte imediato representa risco operacional elevado.

A operação paralela tem duração máxima definida no Plano de Transição — nunca é aberta sem data de encerramento.

49.11.2 Regras de Operação Paralela

• novas solicitações e atendimentos são iniciados apenas na plataforma desde o início da operação paralela;
• processos iniciados anteriormente e ainda em andamento continuam em seu fluxo original até conclusão natural;
• dados criados na plataforma durante o período paralelo não são retroalimentados em processos paralelos;
• o Data Steward acompanha a diminuição do volume em processos paralelos ao longo do período;
• ao final do período, todos os processos pendentes são encerrados ou migrados individualmente para a plataforma.

49.11.3 Coexistência e Identidade do Cidadão

Durante a operação paralela, o mesmo cidadão pode existir em dois contextos. A identidade na plataforma é a fonte de verdade para novos atendimentos. O histórico carregado é somente leitura — nenhum dado histórico é alterado retroativamente pela operação na plataforma.

49.12 Fase 7 — Cutover

49.12.1 Critérios de Cutover

O cutover é autorizado pelo Gestor de Transição do Órgão e pelo Gestor de Produto após verificar:

• todos os critérios de aceite da Fase 5 atendidos;
• operação paralela encerrada (ou zero processos pendentes nos fluxos anteriores);
• equipe do órgão treinada e habilitada;
• suporte de plantão confirmado para as primeiras 48h após o cutover;
• plano de reversão ainda viável e documentado.

49.12.2 Comunicação do Cutover

O cronograma de comunicação antes do cutover:

49.12.3 Execução do Cutover

Janela de Cutover (fora do horário de pico)
    │
Snapshot final dos dados de operações paralelas
    │
Carga de dados residuais (processos iniciados no período paralelo)
    │
Reconciliação final
    │
Validação de saúde da plataforma
    │
Confirmação formal do Gestor de Transição
    │
Plataforma declarada como sistema de registro oficial
    │
Comunicação de conclusão a todos os públicos

49.12.4 Rollback

O plano de rollback define as condições em que o cutover é revertido:

• falha crítica de funcionalidade detectada nas primeiras N horas;
• volume de erros acima do threshold acordado;
• incidente de segurança relacionado à transição;
• solicitação formal do Gestor de Transição do Órgão.

O rollback reverte a operação para o estado anterior ao cutover. Dados criados na plataforma durante o período pós-cutover são exportados e preservados antes do rollback.

A decisão de rollback tem prazo máximo: após 72 horas sem rollback acionado e com operação estável, o plano de rollback é encerrado formalmente.

49.13 Fase 8 — Encerramento

49.13.1 Desativação de Processos Paralelos

Após o cutover confirmado, os processos operacionais anteriores ao escopo da plataforma são encerrados de forma ordenada:

• confirmação de que nenhum processo ativo permanece fora da plataforma;
• arquivamento de registros históricos fora do escopo de carga (quando aplicável);
• revogação de acessos a sistemas e ferramentas que foram substituídos;
• encerramento de integrações ponto-a-ponto substituídas pela plataforma.

49.13.2 Documentação de Encerramento

O encerramento é documentado com:

• data e hora do corte definitivo;
• relação de processos encerrados com responsável;
• confirmação de arquivo ou descarte de dados fora do escopo;
• aprovação formal do Gestor de Transição do Órgão.

49.14 Infrastructure para Carga de Dados

49.14.1 Migration Service

O Migration Service é um componente técnico desenvolvido pela Parceira para cada carga. Ele não é parte da plataforma em produção — é executado em ambiente controlado durante a janela de carga e desativado após o encerramento.

Características:

• acesso restrito ao ambiente de destino;
• autenticação e autorização específicas para o contexto de carga;
• log detalhado de cada registro (LOADED, SKIPPED, FAILED + motivo);
• checkpoint para retomada após interrupção;
• rate limiting para não impactar outros tenants em produção;
• auditoria completa de todas as operações de escrita.

49.14.2 Estratégia de Acesso ao Banco

A carga pode ocorrer por duas estratégias, definidas pelo volume e pela complexidade de transformação:

Via API da Plataforma: a carga passa pela API REST dos serviços de domínio. Mantém todas as validações de negócio, auditoria e eventos. Adequada para volumes menores e dados que precisam de validação completa.

Via inserção direta em banco (com protocolo): para volumes muito grandes em que a API seria um gargalo, a inserção direta em banco é avaliada. Exige: protocolo de segurança aprovado, transação de dados com criptografia em trânsito, auditoria manual dos registros inseridos, validação pós-inserção via API de consulta, e aprovação da equipe de segurança.

49.14.3 Transferência Segura de Dados de Origem

Dados do órgão não são enviados por canais inseguros. O protocolo de transferência define:

• canal de transmissão criptografado (TLS 1.2+ ou SFTP com chave RSA);
• dados pessoais minimizados antes da transferência quando possível;
• arquivo de origem deletado do ambiente de transição após carga bem-sucedida;
• nenhum dado de origem armazenado em repositório de código ou email corporativo.

49.15 Transição e LGPD

49.15.1 Base Legal para a Carga

A carga de dados históricos de um órgão na plataforma é fundamentada na mesma base legal que justifica o tratamento original: o órgão é o controlador dos dados; a PRODEMGE é a operadora; a Parceira é a suboperadora. A transferência ocorre no contexto do contrato e não constitui novo tratamento com base legal distinta.

49.15.2 Minimização na Carga

Somente os dados necessários ao escopo de funcionamento da plataforma são carregados. Campos que não têm uso funcional identificado não são carregados mesmo que existam na origem.

49.15.3 Dados Pessoais Sensíveis

Dados pessoais sensíveis (saúde, renda, biometria) exigem aprovação formal adicional do DPO do órgão antes da inclusão no escopo de carga. A carga desses dados segue protocolo de segurança reforçado.

49.15.4 Direitos de Titulares Pós-Carga

Após a carga, os dados históricos estão sujeitos aos mesmos direitos de titulares que os dados produzidos diretamente na plataforma. O fluxo de atendimento a direitos de titulares descrito no Capítulo 44 aplica-se integralmente aos dados carregados.

49.16 Qualidade de Dados na Transição

49.16.1 Perfil de Qualidade da Origem

Antes do planejamento da carga, o perfil de qualidade dos dados de origem é avaliado:

• completude por campo obrigatório;
• porcentagem de valores nulos em campos esperados;
• duplicatas por chave de negócio;
• formatos inconsistentes (datas, telefones, CPF);
• encoding de caracteres;
• registros com dados claramente incorretos (ex.: data de nascimento futura).

49.16.2 Thresholds de Qualidade

O Plano de Transição define thresholds mínimos por campo crítico:

Campos abaixo do threshold bloqueiam a carga do conjunto.

49.16.3 Tratamento de Dados com Qualidade Baixa

Registros que não atendem os thresholds entram em Quarantine de transição:

• são carregados com flag DATA_QUALITY_WARNING;
• ficam visíveis ao Data Steward para revisão manual;
• não interferem na operação normal da plataforma;
• são resolvidos pelo Data Steward no prazo definido no Plano de Transição.

49.17 Comunicação com Cidadãos

Quando a transição implica que o cidadão passe a interagir com a plataforma para serviços que antes ocorriam por outros meios, a comunicação é planejada com antecedência.

O plano de comunicação define:

• quem precisa ser informado e quando;
• canal de comunicação (portal, app, e-mail, atendimento presencial, comunicado oficial);
• conteúdo da comunicação (o que muda, o que permanece, como o cidadão acessa o serviço agora);
• central de dúvidas durante o período de transição;
• como o cidadão acessa seu histórico carregado na plataforma.

O órgão é responsável pela comunicação ao cidadão. A plataforma oferece os canais e os templates necessários.

49.18 Indicadores da Transição

49.19 Rastreabilidade com o Edital

49.20 Benefícios da Abordagem

• risco de perda de dados minimizado por reconciliação obrigatória em cada fase;
• operação paralela com duração limitada protege o cidadão durante a transição;
• pipeline idempotente permite retomada sem reprocessamento em caso de falha;
• qualidade avaliada antes da carga evita surpresas na operação;
• plano de rollback testado garante reversibilidade até o ponto de corte;
• separação entre Migration Service e plataforma em produção limita blast radius;
• LGPD respeitada na transferência, na carga e no pós-carga com os mesmos direitos dos dados nativos.

49.21 Riscos e Mitigações

49.22 ADRs

49.23 Considerações Finais

A transição operacional é o momento mais crítico da jornada de um órgão para a plataforma. É onde o planejamento encontra a realidade dos dados, dos processos e das pessoas. Uma transição bem executada — com dados íntegros, operação paralela controlada e cutover validado — constrói a confiança dos gestores e dos cidadãos no serviço digital. Uma transição mal conduzida compromete dados, cria operação paralela permanente e gera desconfiança que demora ciclos para recuperar.

O rigor das fases, a obrigatoriedade da reconciliação e a exigência de aceite formal em cada etapa não são burocracia — são os controles que garantem que o órgão entre na plataforma com integridade e saia de processos anteriores com segurança.

O Capítulo 50 detalha a Capacitação e Transferência de Conhecimento.

49.24 Controle de Versão

49.25 Rastreabilidade PRODEMGE

• [PNR] — Seção 3.4.1 (Implantação da Solução): planejamento, configuração, integração e validação; preparação do ambiente produtivo e entrada em operação (go-live).
• [PNR] — Seção 3.4.2 (Onboarding e Configuração Inicial): processo estruturado de carga de dados e definição de fluxos iniciais como parte da adoção da plataforma.
• [ANX-III] Bloco 6 — Infraestrutura e Governança: rastreabilidade, auditoria e conformidade durante a transição.
• [ANX-V] — Sustentabilidade: scripts idempotentes com checkpoint, qualidade verificada em cada fase, encerramento ordenado de processos substituídos.
• [ANX-VII] Cláusula 17 — Operadora (Parceira) e Suboperadora tratando dados do titular conforme orientação da Controladora (PRODEMGE); LGPD respeitada em toda a cadeia de transferência.
• [EDITAL] — Edital CP001/2026: plataforma com processo estruturado de implantação, incorporação de dados e transição controlada para operação plena.