Operadora de saúde: migração de datacenter para AWS em 9 meses

Resumo executivo

Cliente: Operadora de saúde com ~1,2 milhão de vidas e presença nacional. Nome sob NDA. Setor: Saúde suplementar. Duração: 9 meses (março a novembro de 2025). Time Redgator: 1 tech lead, 4 cloud engineers, 1 SRE, 1 DBA sênior, 1 especialista em segurança — operando em squad dedicado, integrado com o time interno do cliente. Resultado principal: 47 sistemas críticos migrados dentro do prazo, TCO anual 32% menor, compliance LGPD + ANS mantido continuamente.

“A Redgator entrou com um plano que a gente nunca tinha conseguido formalizar internamente. Em 9 meses, saímos de um datacenter crítico que era um risco de negócio para uma infraestrutura que reduz custo, aumenta resiliência e ainda deixou nosso time mais forte.” — Diretor de TI, Operadora (sob NDA)

O desafio

A operadora mantinha dois datacenters próprios em São Paulo e Campinas, cobrindo 47 sistemas críticos: core de autorização, sistema de faturamento, integração TISS com prestadores, portal de beneficiários, apps mobile e um data warehouse Oracle de 18 TB.

O contexto estava apertando:

Hardware crítico chegando no fim de vida. Servidores comprados em 2019 com contratos de suporte expirando em 2026. Renovação estimada em R$ 12 MM upfront.
Incidentes de downtime crescendo. Quatro incidentes P1 em 2024, cada um com 4-8 horas de RTO e impacto direto em atendimento clínico.
Compliance ANS + LGPD demandava controles que o datacenter atual não suportava nativamente (segregação de ambientes, cifra de dados em repouso, trilha de auditoria imutável).
Equipe de infraestrutura saturada. 60% do tempo dos 4 sysadmins ia em firefighting, zero em modernização.

O board já havia aprovado verba para “fazer algo sobre o datacenter” mas não tinha plano técnico. A tentativa anterior com outro fornecedor tinha parado em apresentação porque o escopo cresceu sem controle.

A abordagem

Dividimos o programa em 4 fases com critérios de aceite mensuráveis em cada uma. Nada avança até a anterior ter o sinal verde formal.

Fase 1 — Descoberta e mapa de dependências (semanas 1-4)

Entrevistas com 14 líderes técnicos do cliente
Inventário dos 47 sistemas: stack, volumes, criticidade, dependências, donos
Teste de extração de um sistema médio para AWS em sandbox (prova de conceito)
Classificação LGPD de cada sistema: dado sensível, pessoal comum, anonimizado
Modelo de negócio do TCO atual vs TCO AWS projetado em 3 cenários (conservador/médio/agressivo)

Deliverable: Migration Blueprint — 54 páginas, aprovado pelo board.

Fase 2 — Landing zone e fundação (semanas 5-10)

AWS Organization com 6 accounts: prod-core, prod-data, staging, sandbox, security, shared-services
VPCs com peering e Transit Gateway, conectadas ao datacenter via Direct Connect 10 Gbps
Terraform como IaC exclusivo (zero click-ops em produção)
KMS com CMK por classe de dados, cifra em trânsito (TLS 1.2+) e em repouso (AES-256)
CloudTrail + Config + Security Hub + GuardDuty ativos, logs em S3 com Object Lock (WORM) por 7 anos para compliance ANS
Datadog para observabilidade unificada

Critério de aceite: auditoria interna de segurança aprova a landing zone antes de qualquer workload migrar.

Fase 3 — Migração em 4 ondas (semanas 11-32)

Priorização pelo mix criticidade baixa + dependências baixas primeiro, trazendo os sistemas mais críticos por último, quando o time já tinha confiança.

Onda 1 — 12 sistemas de apoio: portais internos, automações RPA, sistemas de gestão de fornecedores. Padrão: rehost + rightsizing. Tempo médio: 2 semanas por sistema.

Onda 2 — 18 sistemas de médio impacto: integrações TISS, sistemas de prestadores, ferramentas de BI. Padrão: rehost + refactor de logs/métricas para CloudWatch + Datadog. Downtime negociado: 2-4h fins de semana.

Onda 3 — 12 sistemas customer-facing: portal beneficiário, apps mobile, call center tech. Padrão: replatform com Aurora PostgreSQL (onde aplicável) + ECS Fargate. Blue/green deployment via ALB + Route53 weighted.

Onda 4 — 5 sistemas core críticos: core de autorização, sistema de faturamento, data warehouse Oracle (18 TB), integração com SUS, motor de elegibilidade. Padrão: híbrido rehost + replatform com data replication (Oracle GoldenGate para o DW; AWS DMS para sistemas menores). Janela de downtime: 4h máximo, em madrugada de domingo, com rollback plan validado.

Fase 4 — Handover, FinOps e evolução contínua (semanas 33-36)

Treinamento de 3 bootcamps de 40h para o time interno (fundamentos AWS, Terraform prático, segurança cloud)
Runbooks criados e validados para os 47 sistemas
Dashboard de FinOps em produção, com alertas de anomalia e relatório mensal de rightsizing
Transição do tech lead para papel de advisor mensal (checkpoint de 4h/mês) por 6 meses

Decisões técnicas-chave

Decisão 1 — Account strategy

Contexto: o cliente queria uma conta só para simplificar billing. Segurança e compliance empurravam para múltiplas contas.

Alternativas: 1 account; 3 accounts (prod/non-prod/security); 6 accounts com AWS Organization.

Decisão: 6 accounts. Complexidade inicial maior, mas dá segregação nativa de prod vs não-prod em nível de IAM, de limite de spend, de raio de explosão em caso de comprometimento.

Resultado: em um incidente simulado (red team interno), comprometer credenciais de staging não deu acesso a prod — exatamente o comportamento desejado. A separação pagou-se na primeira auditoria ANS.

Decisão 2 — Oracle: migrar agora ou depois

Contexto: o data warehouse Oracle (18 TB) era o workload mais caro e complexo. Migrar para Redshift ou Aurora seria um projeto de 6+ meses por si.

Alternativas: (a) replatform para Redshift imediatamente; (b) rehost Oracle em RDS for Oracle; (c) rehost Oracle em EC2 BYOL.

Decisão: (c) EC2 BYOL em primeira fase. Aceitamos que o DW seguiria em Oracle por mais 12-18 meses, enquanto o novo data platform (BigQuery + dbt + lakehouse) seria construído em paralelo, com migração de cargas por domínio.

Resultado: o programa de migração terminou no prazo sem o risco de escopo que um replatform de DW traria. A transição para lakehouse agora está em curso em um programa separado.

Decisão 3 — Observabilidade unificada

Contexto: o cliente tinha Splunk on-prem, Zabbix, APMs locais diferentes por sistema. Na AWS, multiplicar isso seria caro e heterogêneo.

Alternativas: CloudWatch nativo; Datadog; manter Splunk via agente.

Decisão: Datadog como single pane of glass, com OpenTelemetry onde o time tinha fluência e agente Datadog onde precisavam de tempo-para-valor menor. Splunk foi descomissionado após 4 meses.

Resultado: custo de observabilidade 40% menor que o somatório on-prem, MTTR dos incidentes P2 reduziu pela metade.

Números

Métrica	Antes (DC próprio)	Depois (AWS)	Delta
Custo mensal infra	R$ 2,85 MM	R$ 1,94 MM	-32%
Incidentes P1/ano	4	0 (em 4 meses obs.)	-100%
RTO sistemas críticos	8 horas	< 1 hora	-87%
Deploy frequency	1x/semana médio	2x/dia médio	+8x
Lead time for change	14 dias	2 dias	-85%
Uptime consolidado	99.82%	99.96%	+0.14pp
Cobertura de testes automatizados	~15%	~62%	+47pp

Tecnologias e práticas

Cloud: AWS (regiões sa-east-1 e us-east-1 para DR)
IaC: Terraform, módulos próprios com padrão Redgator
Compute: ECS Fargate (maioria) + EC2 para Oracle + Lambda para jobs batch
Database: Aurora PostgreSQL, RDS, Oracle em EC2 BYOL, DynamoDB para sessões
Rede: Transit Gateway, Direct Connect 10 Gbps, Route53 resolver
Segurança: KMS, Secrets Manager, WAF, Shield Standard, Security Hub, GuardDuty
Observabilidade: Datadog (APM + logs + infra), CloudWatch para métricas AWS nativas
CI/CD: GitLab + AWS CodePipeline, GitLab Runner em Fargate
Compliance: S3 Object Lock (WORM) para logs de auditoria, CloudTrail Organization-level, AWS Config rules para ANS/LGPD

O que funcionou bem

Squad dedicado, não “body shop”. O time Redgator operou como extensão do time do cliente, com responsabilidade por outcome, não por horas.
Landing zone antes de qualquer workload. Gastar 6 semanas fundando a infra direito pagou-se em velocidade no resto.
Waves com critério de aceite formal. Nenhuma onda avançou sem sinal verde; evitou arrastar bugs de onda anterior.
Treinamento do time interno desde a semana 1. O cliente assumiu operação com autonomia real, não dependência.
FinOps desde o mês 2. Tags, alertas e rightsizing começaram antes do go-live, não depois.

O que faríamos diferente

Começaríamos o POC de GoldenGate 8 semanas antes. Subestimamos o tempo de setup de replicação entre DC e AWS para o Oracle DW — atrasou 3 semanas a onda 4.
Envolveríamos a área jurídica do cliente mais cedo na discussão sobre AWS Artifact (relatórios SOC 2, HIPAA-like). Tivemos que voltar em semana 10 para coletar evidências que poderiam ter sido pré-validadas na semana 2.
Investiríamos mais em canary deployments na onda 3. Fizemos blue/green, que funcionou, mas canary teria dado rollback mais granular em 2 dos bugs de produção (ambos resolvidos em < 30 min, mas poderiam ter sido em < 5).

Próximos passos

Após o go-live, a parceria continua em formato reduzido:

4h/mês de advisory do tech lead por 6 meses
Programa separado de data platform moderna em andamento (BigQuery + dbt + lakehouse)
Handover formal para o time interno assumir operação completa até março/2026

Depoimento

“A gente já tinha tentado migrar antes com outro parceiro e o projeto simplesmente não andava. Com a Redgator, o diferencial foi o plano honesto desde o dia um, o rigor em cada fase, e principalmente como eles transferiram conhecimento real para nossa equipe. Hoje, quatro meses depois do go-live, meu time opera a AWS com autonomia que eu não achei possível. Cortamos 32% do custo, mas a conversa maior é que eliminamos um risco estratégico do nosso negócio.”

— Diretor de TI, Operadora (sob NDA)

Case publicado em 15/11/2025. Nomes e alguns detalhes técnicos foram generalizados para proteger informações competitivas e compliance contratual. Números apresentados com autorização do cliente.

Operadora de saúde — Migração de datacenter para AWS com compliance LGPD/ANS