Analise estratégias de migração de sistemas SAP para o Microsoft Azure

Concluído

A maioria dos clientes que consideram implantar cargas de trabalho SAP no Azure tem uma implementação SAP local existente. O número de implantações greenfield é relativamente pequeno.

Normalmente, as empresas têm sistemas SAP para funções de negócios como planejamento de recursos empresariais (ERP), comércio global, business intelligence (BI) e outros. Dentro desses sistemas estão ambientes como sandbox, desenvolvimento, teste e produção.

Diagrama mostrando ambientes de exemplo.

Cada linha horizontal na figura acima é um ambiente. Cada coluna é um sistema SAP para uma função de negócios (por exemplo, ERP e BI).

As linhas ou camadas na parte inferior são ambientes de menor risco e são menos críticas. Aqueles que estão no topo são de maior risco e mais críticos. À medida que você sobe na pilha, há mais risco no processo de migração. Portanto, a produção é o ambiente mais crítico, e o ambiente para testes de aceitação do usuário (Test) — que também é usado para continuidade de negócios — é o segundo mais crítico.

Os sistemas na parte inferior são menores, na medida em que têm menos recursos de computação, menor disponibilidade e requisitos de tamanho, e menos taxa de transferência. No entanto, eles têm a mesma quantidade de armazenamento que o banco de dados de produção.

Estratégia horizontal

Com uma estratégia horizontal, você começa da parte inferior da pilha porque é uma maneira segura de experimentar e ganhar experiência com o Azure. Também é uma boa estratégia para usar enquanto você redefine seus processos operacionais, de implantação e de aprovação. Esses processos serão alterados à medida que você se move para o Azure. Veja como funciona a estratégia:

  • Para limitar o risco, comece com sistemas de treinamento ou sandbox de baixo impacto. Se algo der errado, há muito pouco perigo de afetar muitos usuários ou funções de negócios de missão crítica.
  • Em seguida, à medida que você ganha experiência com a execução, hospedagem e administração de sistemas SAP no Azure, aplique o que aprendeu à próxima camada de sistemas acima da pilha.
  • Para cada camada, estime os custos, o dinheiro potencial economizado, o desempenho e o potencial de otimização — e ajuste, se necessário.

Estratégia vertical

Para ganhar experiência com sistemas de produção no Azure, você pode usar uma estratégia vertical com sistemas de baixo risco em paralelo à estratégia horizontal. Isso também oferece uma chance de ajustar processos internos para o Azure e treinar os membros da equipe. É uma ótima maneira de detetar quaisquer problemas na produção logo no início. Veja como funciona a estratégia:

  • Analise o impacto no custo, nos clientes, nos contratos de nível de serviço (SLAs) e nos requisitos legais. Primeiro, mova os sistemas — da área restrita até a produção — que têm o menor risco: o sistema de governança, risco e conformidade e, em seguida, o sistema de repositório de eventos de objeto (OER). Em seguida, mova os de maior risco, como BI e ERP.
  • Quando você tiver um novo sistema SAP, comece no Azure por padrão, em vez de colocá-lo no local e movê-lo mais tarde. No diagrama, os REA são um exemplo disso. Os REA são um sistema novo e de baixo risco. Depois de mover alguns de nossos outros sistemas para o Azure com a estratégia horizontal, você pode implantar toda a pilha vertical de REA no Azure, de ponta a ponta, desde a área restrita até a produção.
  • Não mova o seu sistema mais crítico primeiro. O último sistema que você move é o sistema de maior risco e mais crítico: o sistema de produção ERP. Você precisa das SKUs de máquina virtual de maior desempenho e do maior armazenamento.
  • Mova sistemas autônomos primeiro. Alguns sistemas estão intimamente ligados a outros sistemas, por exemplo, nossos sistemas ERP e GTS. Há muito tráfego síncrono e em tempo real entre os dois. Se você mover o ERP para o Azure, mas mantiver o GTS local, isso afetará o desempenho devido à latência da rede, portanto, mova-os juntos.
  • Se você tiver vários sistemas SAP, procure dependências upstream e downstream de um sistema SAP para o outro, ou do SAP para aplicativos fora do ecossistema SAP. Examine padrões de tráfego e áreas com alta sensibilidade à latência.
  • Se você tiver sistemas bem conectados, faça uma análise de desempenho para ver o efeito que movê-los terá. Se não houver muito impacto, mova-os separadamente para o Azure (por exemplo, Business Warehouse independente do ERP). Caso contrário, crie grupos de migração e mova-os juntos.
  • Em alguns casos, considere esperar. Às vezes, você não deseja mover determinados sistemas para o Azure imediatamente. Isso pode estar relacionado aos requisitos de dimensionamento quando os requisitos de processamento eram tão altos que as máquinas virtuais ainda não eram grandes o suficiente. Execute testes para garantir que a movimentação desses sistemas não afetará os SLAs com os clientes.