Analysera strategier för att migrera SAP-system till Microsoft Azure

  • 10 minuter

De flesta kunder som överväger att distribuera SAP-arbetsbelastningar till Azure har en befintlig lokal SAP-implementering. Antalet greenfield-distributioner är relativt litet.

Företag har vanligtvis SAP-system för affärsfunktioner som affärsresursplanering (ERP), global handel, Business Intelligence (BI) och andra. I dessa system finns miljöer som sandbox-miljö, utveckling, testning och produktion.

Diagram som visar exempelmiljöer.

Varje vågrät rad i bilden ovan är en miljö. Varje kolumn är ett SAP-system för en affärsfunktion (till exempel ERP och BI).

Raderna eller lagren längst ned är miljöer med lägre risk och är mindre kritiska. De mot toppen är högre risk och mer kritiska. När du flyttar upp stacken finns det större risk i migreringsprocessen. Därför är produktion den mest kritiska miljön, och miljön för testning av användargodkännande (test) – som också används för affärskontinuitet – är den näst mest kritiska.

Systemen längst ned är mindre eftersom de har färre beräkningsresurser, lägre tillgänglighet och storlekskrav och mindre dataflöde. De har dock samma mängd lagringsutrymme som produktionsdatabasen.

Horisontell strategi

Med en horisontell strategi börjar du längst ned i stacken eftersom det är ett säkert sätt att experimentera och få erfarenhet av Azure. Det är också en bra strategi att använda när du omdefinierar dina processer för drift, distribution och godkännande. Dessa processer ändras när du flyttar till Azure. Så här fungerar strategin:

  • Om du vill begränsa risken börjar du med sandbox- eller träningssystem med låg påverkan. Om något går fel finns det mycket liten risk att påverka många användare eller verksamhetskritiska affärsfunktioner.
  • När du sedan får erfarenhet av att köra, vara värd för och administrera SAP-system i Azure kan du tillämpa det du har lärt dig för nästa lager av system i stacken.
  • För varje lager beräknar du kostnader, potentiella sparade pengar, prestanda och optimeringspotential – och justerar vid behov.

Vertikal strategi

För att få erfarenhet av produktionssystem i Azure kan du använda en vertikal strategi med lågrisksystem parallellt med den horisontella strategin. Detta ger också möjlighet att justera interna processer för Azure och träna teammedlemmar. Det är ett bra sätt att upptäcka eventuella problem i produktionen tidigt. Så här fungerar strategin:

  • Titta på påverkan på kostnader, kunder, serviceavtal (SLA) och juridiska krav. Flytta först system – från sandbox-miljö till produktion – som har den lägsta risken: styrnings-, risk- och efterlevnadssystemet och sedan OER-systemet (Object Event Repository). Flytta sedan de med högre risk, till exempel BI och ERP.
  • När du har ett nytt SAP-system startar du som standard i Azure i stället för att placera det lokalt och flytta det senare. I diagrammet är OER ett exempel på detta. OER är ett nytt lågrisksystem. När du har flyttat några av våra andra system till Azure med den horisontella strategin kan du distribuera hela den lodräta OER-stacken till Azure, från slutpunkt till slutpunkt, från sandbox-miljö hela vägen upp till produktion.
  • Flytta inte ditt mest kritiska system först. Det sista systemet du flyttar är den högsta risken, det mest verksamhetskritiska systemet – ERP-produktionssystemet. Du behöver de mest prestandaintensiva SKU:erna för virtuella datorer och den största lagringen.
  • Flytta fristående system först. Vissa system är nära kopplade till andra system, till exempel våra ERP- och GTS-system. Det finns mycket synkron realtidstrafik mellan de två. Om du flyttar ERP till Azure men behåller GTS lokalt påverkar det prestanda på grund av nätverksfördröjning – så flytta dem tillsammans.
  • Om du har flera SAP-system letar du efter uppströms- och nedströmsberoenden från ett SAP-system till ett annat, eller från SAP till appar utanför SAP-ekosystemet. Granska trafikmönster och områden med hög känslighet för svarstid.
  • Om du har nära anslutna system kan du göra en prestandaanalys för att se vilken effekt det kommer att få att flytta dem. Om det inte finns någon större inverkan flyttade du dem separat till Azure (till exempel Business Warehouse oberoende av ERP). Annars skapar du migreringsgrupper och flyttar dem tillsammans.
  • I vissa fall bör du överväga att vänta. Ibland vill du inte flytta vissa system till Azure direkt. Detta kan vara relaterat till storlekskrav när bearbetningskraven var så höga att de virtuella datorerna ännu inte var tillräckligt stora. Kör tester för att säkerställa att flytt av dessa system inte kommer att påverka serviceavtal med kunder.