O coordenador de TI recebe a missão: trocar o PACS. O sistema atual está defasado, o suporte é ruim, o contrato ficou caro, a operação reclama de lentidão. A diretoria quer mudança. O radiologista quer mudança. Todo mundo quer mudança.
Até alguém perguntar: “E durante a migração, como fica a operação?”
É aí que o projeto empaca. Porque migrar PACS não é como trocar um software de escritório. É trocar o coração da operação de imagem. Se parar, o hospital para de laudar. Se der problema, pacientes ficam sem diagnóstico.
O medo é legítimo. Mas migração sem parada é possível. Exige planejamento, arquitetura correta e execução disciplinada.
Por que migração de PACS é diferente
Trocar um ERP é complicado, mas tem uma data de virada. No dia X, desliga o antigo e liga o novo. Se der problema, a empresa atrasa processos internos, mas ninguém deixa de ser atendido.
PACS não funciona assim. Enquanto a migração acontece, exames continuam sendo realizados. Cada tomografia, cada ressonância, cada raio-x precisa ser armazenado, disponibilizado e laudado. Não existe “pausar a produção de exames” enquanto a TI resolve a transição.
Além disso, existe o histórico. Anos de imagens armazenadas no sistema antigo. Milhões de arquivos DICOM que precisam continuar acessíveis. O radiologista que abre um exame novo precisa conseguir comparar com o exame de 3 anos atrás que está no sistema legado.
Migração de PACS é trocar o motor com o avião voando e ainda levar toda a bagagem junto.
O modelo de migração que não funciona
O modelo tradicional de migração funciona assim: define uma data de corte, exporta todos os dados do sistema antigo, importa no sistema novo, faz testes, vira a chave.
Na teoria, funciona. Na prática, falha por vários motivos.
Primeiro, a exportação de dados leva tempo. Estamos falando de terabytes, às vezes petabytes de imagens. Transferir esse volume pode levar semanas ou meses, dependendo da infraestrutura.
Segundo, durante a exportação, novos exames continuam sendo gerados. Quando a migração termina, já existe um gap de dados que precisa ser coberto.
Terceiro, o dia da virada concentra todo o risco. Se algo der errado nesse dia, a operação para. E algo sempre dá errado quando você depende de um único momento crítico.
Quarto, o sistema antigo precisa ficar acessível até que 100% dos dados sejam migrados. Isso significa manter duas infraestruturas em paralelo, com dois contratos, dois suportes, duas equipes sabendo operar.
Migração progressiva: o modelo que funciona
A alternativa é migração progressiva, também chamada de migração em coexistência.
Nesse modelo, o sistema novo entra em operação antes de toda a migração de histórico ser concluída. Os novos exames já são armazenados e laudados no sistema novo. O histórico vai sendo transferido em background, aos poucos, sem pressa.
Enquanto isso, os dois sistemas coexistem de forma integrada. Quando o radiologista abre um exame antigo que ainda não foi migrado, o sistema novo busca automaticamente no sistema legado, de forma transparente. O usuário nem percebe de onde veio a imagem.
Esse modelo elimina o dia D do risco. Não existe virada de chave. Existe uma transição gradual onde cada dia o sistema novo assume mais e o sistema antigo assume menos.
Os pré-requisitos técnicos
Migração progressiva exige que o sistema novo tenha capacidade de federação: consultar e exibir imagens que estão em outro repositório como se fossem locais.
Nem todo PACS oferece isso de forma nativa. Muitos exigem que toda a base esteja local para funcionar. Esses sistemas forçam o modelo de migração tradicional, com todos os seus riscos.
A arquitetura do sistema novo também precisa suportar ingestão contínua durante a migração. Enquanto dados históricos estão sendo importados, novos exames estão chegando. As duas operações não podem competir por recursos a ponto de degradar a performance.
Outro pré-requisito é mapeamento de dados. DICOM é um padrão, mas cada fabricante implementa de forma ligeiramente diferente. Campos que no sistema A estão em um lugar, no sistema B estão em outro. Identificadores de paciente, números de acesso, UIDs de estudo precisam ser mapeados corretamente para que a integridade seja mantida.
O papel do storage híbrido na migração
Migração é o momento em que a arquitetura de storage mais importa.
Se o sistema novo depende de servidor local, a migração exige provisionar capacidade para todo o histórico antes de começar. Isso significa investimento upfront alto e risco de subdimensionamento.
Se o sistema novo opera em modelo híbrido (cache local + nuvem), a migração fica mais flexível. O histórico pode ser transferido diretamente para a nuvem, sem ocupar espaço local. O cache local recebe apenas os exames recentes e os mais acessados.
Nesse modelo, não existe “encher o servidor”. A capacidade de nuvem escala automaticamente conforme a migração avança. O custo é proporcional ao uso, não ao pico projetado.
Validação de integridade: o que não pode ser pulado
Migrar dados é fácil. Migrar dados corretamente é o desafio.
Cada estudo migrado precisa ser validado: as imagens estão completas? Os metadados estão corretos? O estudo está associado ao paciente certo? A série está na ordem correta?
Validação manual é inviável quando estamos falando de milhões de estudos. O processo precisa ser automatizado, com verificação de checksum, contagem de instâncias e conferência de metadados críticos.
Estudos que falham na validação vão para uma fila de exceção, onde são tratados individualmente. Esse tratamento de exceção precisa estar previsto no cronograma. Em toda migração, um percentual de dados apresenta problemas que exigem intervenção manual.
Comunicação com a operação
A TI sabe o que está acontecendo durante a migração. A operação muitas vezes não sabe.
Comunicação proativa evita ruído. O radiologista precisa saber que, durante algumas semanas, exames muito antigos podem demorar alguns segundos a mais para abrir (porque estão sendo buscados no sistema legado). Precisa saber qual canal usar se encontrar algum exame que não aparece. Precisa saber que o histórico completo estará disponível até a data X.
Sem essa comunicação, qualquer lentidão vira “o sistema novo é pior que o antigo”. A percepção da migração fica contaminada por expectativas desalinhadas.
Cronograma realista
Migrações de PACS em hospitais de médio porte levam de 3 a 6 meses para conclusão completa do histórico. Hospitais grandes, com décadas de imagens armazenadas, podem levar mais de um ano.
Esses prazos assustam, mas não significam que a operação fica instável durante todo o período. Com migração progressiva, o sistema novo está plenamente operacional desde a primeira semana. O que leva meses é a transferência completa do histórico, que acontece em background sem impactar o dia a dia.
O erro comum é prometer prazos agressivos para agradar a diretoria e depois enfrentar os problemas de uma migração apressada. Migração de PACS não é projeto para heroísmo. É projeto para método.
Rollback: o plano B que você espera nunca usar
Todo projeto de migração precisa ter plano de rollback. Se algo der errado de forma irrecuperável, como voltar para o sistema antigo?
No modelo de migração progressiva, rollback é menos traumático porque o sistema antigo nunca foi desligado. Ele continua recebendo cópias dos exames novos (ou pelo menos dos metadados) durante o período de transição. Se for necessário voltar, a operação retoma de onde estava.
No modelo de virada de chave, rollback significa religar um sistema que foi desativado, reimportar dados que foram modificados, reconectar equipamentos que foram reconfigurados. É caótico e demorado.
A melhor forma de nunca precisar do rollback é planejar como se fosse precisar.
O que muda depois da migração
Migração bem feita não é só trocar de sistema. É oportunidade de corrigir problemas estruturais que se acumularam ao longo dos anos.
Dados duplicados podem ser limpos. Estudos órfãos podem ser associados aos pacientes corretos. Padrões de nomenclatura podem ser unificados. Fluxos de trabalho podem ser redesenhados para aproveitar funcionalidades que o sistema antigo não tinha.
Tratar migração apenas como “copiar dados de A para B” é desperdiçar a chance de sair melhor do que entrou.
