Strategieën analyseren voor het migreren van SAP-systemen naar Microsoft Azure

Voltooid

De meeste klanten die overwegen SAP-workloads in Azure te implementeren, hebben een bestaande on-premises SAP-implementatie. Het aantal greenfield-implementaties is relatief klein.

Normaal gesproken hebben ondernemingen SAP-systemen voor bedrijfsfuncties zoals ERP (Enterprise Resource Planning), global trade, business intelligence (BI) en andere. Binnen deze systemen zijn omgevingen zoals sandbox, ontwikkeling, test en productie.

Elke horizontale rij in de bovenstaande afbeelding is een omgeving. Elke kolom is een SAP-systeem voor een bedrijfsfunctie (bijvoorbeeld ERP en BI).

De rijen of lagen onderaan zijn omgevingen met een lager risico en zijn minder kritiek. Die naar het hoogste niveau zijn hoger risico en kritischer. Naarmate u de stapel omhoog beweegt, bestaat er meer risico in het migratieproces. Productie is dus de meest kritieke omgeving en de omgeving voor het testen van gebruikersacceptatie (test) die ook wordt gebruikt voor bedrijfscontinuïteit, is de op een na meest kritieke omgeving.

De systemen onderaan zijn kleiner, omdat ze minder rekenresources hebben, lagere vereisten voor beschikbaarheid en grootte en minder doorvoer. Ze hebben echter dezelfde hoeveelheid opslagruimte als de productiedatabase.

Horizontale strategie

Met een horizontale strategie begint u vanaf de onderkant van de stack omdat het een veilige manier is om te experimenteren en ervaring te krijgen met Azure. Het is ook een goede strategie om te gebruiken terwijl u uw operationele, implementatie- en goedkeuringsprocessen opnieuw definieert. Deze processen worden gewijzigd wanneer u overstapt naar Azure. De strategie werkt als volgt:

• Als u het risico wilt beperken, begint u met sandbox- of trainingssystemen met een lage impact. Als er iets misgaat, is er weinig gevaar voor veel gebruikers of bedrijfskritieke bedrijfsfuncties.
• Wanneer u ervaring krijgt met het uitvoeren, hosten en beheren van SAP-systemen in Azure, past u vervolgens toe wat u hebt geleerd op de volgende laag van systemen die de stack vormen.
• Schat voor elke laag kosten, potentieel geld bespaard, prestatie- en optimalisatiepotentieel, en pas indien nodig aan.

Verticale strategie

Als u ervaring wilt opdoen met productiesystemen in Azure, kunt u een verticale strategie met systemen met een laag risico parallel aan de horizontale strategie gebruiken. Dit biedt ook de mogelijkheid om interne processen voor Azure aan te passen en teamleden te trainen. Het is een geweldige manier om eventuele problemen in productie vroeg op te sporen. De strategie werkt als volgt:

• Bekijk de impact op kosten, klanten, serviceovereenkomsten (SLA's) en wettelijke vereisten. Verplaats eerst systemen, van sandbox tot productie, met het laagste risico: het governance-, risico- en nalevingssysteem en vervolgens het OER-systeem (Object Event Repository). Verplaats vervolgens de risicovollere, zoals BI en ERP.
• Wanneer u een nieuw SAP-systeem hebt, start u standaard in Azure in plaats van het on-premises te plaatsen en later te verplaatsen. In het diagram is OER een voorbeeld hiervan. OER is een nieuw, laag risicosysteem. Nadat u enkele van onze andere systemen met de horizontale strategie naar Azure hebt verplaatst, kunt u de volledige verticale OER-stack implementeren in Azure, end-to-end, van sandbox tot productie.
• Verplaats uw meest kritieke systeem niet eerst. Het laatste systeem dat u verplaatst is het hoogste risico, het meest bedrijfskritieke systeem, het ERP-productiesysteem. U hebt de meest prestatie-intensieve SKU's voor virtuele machines en de grootste opslag nodig.
• Verplaats eerst zelfstandige systemen. Sommige systemen zijn nauw verbonden met andere systemen, bijvoorbeeld onze ERP- en GTS-systemen. Er is veel synchroon, realtime verkeer tussen de twee. Als u ERP verplaatst naar Azure, maar GTS on-premises houdt, heeft dit invloed op de prestaties vanwege netwerklatentie, zodat u ze samen verplaatst.
• Als u verschillende SAP-systemen hebt, zoekt u naar upstream- en downstreamafhankelijkheden van het ene SAP-systeem naar het andere, of van SAP naar apps buiten het SAP-ecosysteem. Bekijk verkeerspatronen en gebieden met een hoge gevoeligheid voor latentie.
• Als u nauw verbonden systemen hebt, voert u een prestatieanalyse uit om te zien welk effect het verplaatsen ervan heeft. Als er niet veel impact is, verplaatst u ze afzonderlijk naar Azure (bijvoorbeeld Business Warehouse onafhankelijk van ERP). Anders maakt u migratiegroepen en verplaatst u deze samen.
• In sommige gevallen kunt u overwegen om te wachten. Soms wilt u bepaalde systemen niet meteen naar Azure verplaatsen. Dit kan te maken hebben met de groottevereisten wanneer de verwerkingsvereisten zo hoog waren dat de virtuele machines nog niet groot genoeg waren. Voer tests uit om ervoor te zorgen dat het verplaatsen van deze systemen geen invloed heeft op SLA's met klanten.