Skip to main content

Modernização Híbrida do SAP ECC e Transferência Gerenciada de Arquivos na AWS

Descrição Curta do Estudo de Caso

A Dana Cosméticos migrou seu ambiente crítico de SAP ECC on-premises para a AWS por meio de uma modernização híbrida em fases. O projeto incluiu a criação de um ambiente dedicado QAS/SBX, melhoria no controle de releases e implementação de SFTP gerenciado, monitoramento e operações resilientes na AWS.

Problema / Definição

A Dana Cosméticos precisava migrar um ambiente crítico de SAP ECC da infraestrutura on-premises para a AWS, ao mesmo tempo em que modernizava a plataforma.

O cliente operava apenas com ambientes DEV e PRD em um SAP ECC EHP4 legado e precisava:

  • Criar um ambiente dedicado QAS/SBX
  • Alinhar configurações entre DEV, QAS/SBX e PRD
  • Executar um upgrade controlado para SAP ECC EHP8 antes da migração para produção

Sem essa intervenção, a Dana permaneceria dependente de um modelo limitado de dois ambientes, o que:

  • Aumentava o risco de validar mudanças muito próximo da produção
  • Estendia períodos de freeze no DEV durante upgrades
  • Reduzia a qualidade dos releases
  • Mantinha riscos operacionais, de disponibilidade e suporte a longo prazo

Solução Proposta e Arquitetura

O projeto adotou uma abordagem híbrida em fases combinada com modernização operacional.

Camada SAP (parte superior da arquitetura):

  • Ambiente SAP executando em Amazon EC2 dentro de uma VPC dedicada
  • Distribuição em duas Zonas de Disponibilidade
  • Sub-redes públicas e privadas
  • Conectividade híbrida com on-premises via:
    • AWS Site-to-Site VPN
    • Virtual Private Gateway
    • Customer Gateway

Camada de transferência de arquivos (parte inferior):

  • AWS Transfer Family para SFTP (entrada e saída)
  • Amazon S3 para armazenamento RAW e PROCESSED
  • AWS Lambda para autenticação e processamento de arquivos
  • AWS Secrets Manager para credenciais
  • Amazon CloudWatch e AWS CloudTrail para monitoramento e auditoria

A solução foi escolhida em vez de:

  • Permanecer on-premises
  • Fazer apenas rehost (lift-and-shift)
  • Realizar refatoração completa

porque ofereceu o melhor equilíbrio entre:

  • Baixo risco de migração
  • Continuidade de negócio
  • Operação sustentável no longo prazo

A infraestrutura foi automatizada usando Terraform (IaC) integrado a pipeline de CI/CD.

Resultados do Projeto e Métricas de Sucesso

O projeto trouxe melhorias significativas em governança de releases e desempenho de cutover.

KPI 1 – Cobertura de Validação Pré-Produção:

  • Antes: 0% (apenas DEV e PRD)
  • Meta: 100% das mudanças validadas em QAS/SBX antes da produção
  • Resultado: 100% das mudanças passaram por DEV → QAS/SBX → PRD

KPI 2 – Tempo de Downtime no Cutover/Upgrade:

  • Antes: 10–12 horas (estimado em modelo tradicional)
  • Meta: < 4 horas
  • Resultado: 3 horas e 20 minutos

Resiliência (planejamento):

  • RTO: 4 horas
  • RPO: 1 hora

Baseado em:

  • Arquitetura Multi-AZ
  • Redundância de VPN
  • Serviços gerenciados na camada de transferência de arquivos

Lições Aprendidas

  • A baixa disponibilidade de documentação histórica e dados operacionais do ambiente SAP on-premises dificultou:
    • Entendimento do processo de releases
    • Análise de downtime
    • Mapeamento de dependências
  • A ausência de um ambiente QAS/SBX aumentou o esforço de planejamento do upgrade e cutover

 

Melhorias adotadas para próximos projetos:

  • Fase mais estruturada de discovery e readiness
  • Avaliação de infraestrutura e dependências
  • Definição de KPIs baseline
  • Critérios claros de cutover
  • Documentação obrigatória de:
    • Fluxos de aplicação
    • Procedimentos de suporte
    • Planos de rollback
  • Outra lição importante foi definir o modelo operacional desde o início, e não apenas o caminho de migração

Evolução para projetos futuros:

  • Design antecipado do ambiente
  • Checkpoints de validação
  • Ensaios de cutover
  • Procedimentos definidos de monitoramento e recuperação

Leave a Reply