De 5 meest gemaakte fouten bij cloudmigratie

1. Vervangen van jouw datacenter?

Sommige leidinggevenden die ik spreek zien de cloud teveel vanuit het perspectief van een infrastructuur. In dat geval denken ze vaak: laten we migreren en de business versnellen. Maar doe je dat, dan ga je voorbij aan niet-geoptimaliseerde workloads en projecten die maar weinig waarde bieden voor je bedrijf.

Misschien heb je een overeenkomst gesloten met een hyperscaler en moet je de migratie snel in gang zetten. Zo worden veel applicaties opnieuw gehost met de rechtvaardiging "dat er al voor betaald is". Helaas wordt er daarna vaak niet meer naar die apps omgekeken. In het gunstigste geval functioneren ze hetzelfde als toen ze on-premise stonden. Maar doordat ze hetzelfde werken en er hetzelfde uitzien, wordt er cynisch gekeken naar de cloud. Want die gouden bergen die de cloud belooft, worden maar nauwelijks waargenomen.

2. Technische migratie als uitgangspunt?

We zien dat sommige klanten bij de migratie van hun applicaties kijken naar wat technisch het meest geschikt is. Maar dat is vanuit zakelijk oogpunt niet altijd de beste keuze. Want hoewel deze benadering vaak wel eenvoudiger is en voor meer wendbaarheid zorgt tijdens de migratie, kunnen de resultaten teleurstellend zijn voor de business.

Klanten hebben vaak hoge verwachtingen van de cloud. En deze worden nog extra aangewakkerd door de marketingmachine van diverse hyperscalers. Maar wil je mensen overtuigen van de voordelen van de cloud, dan moet je meer bieden dan eenzelfde ervaring als voorheen tegen dezelfde kosten. Dat is zeker belangrijk wanneer er veel IT-resources komen kijken bij het migratieproces, de dagelijkse business wordt beïnvloed en andere strategische projecten worden uitgesteld.

3. Van een best-practices naar een whiteboard benadering?

Veel organisaties vertrouwen op interne aannames over de technische levenscyclus, de consistentie van de architectuur, de kwaliteit van de code en de mogelijkheden voor refactoring. Want waarom zou je goed functionerende code weggooien? Maar doe je vooraf de aanname dat iets wel zal werken, dan ontstaat er vaak een boemerangeffect. Cloudmigraties worden vaak gepland terwijl er te weinig inzicht is in de benodigde wijzigingen in de applicatie. Ook wordt vooraf niet goed bekeken hoe haalbaar het refactoren van specifieke applicaties zal zijn.

En zelfs binnen refactoring zijn er diverse niveaus. Een applicatie refactoren om het geschikt te maken voor PaaS of het oplossen van beveiligingsproblemen kun je niet vergelijken met het volledig vernieuwen van een applicatie op basis van een microservice benadering. Wil je echt weten wat je in huis hebt en waar je tegenaan loopt bij migratie, gebruik dan detectie- en inspectietools, naast de al bekende en erkende methoden. Ontdek meer over refactoring in onze 7R infographic.

4. Verschillende belangen tussen afdelingen?

Bij de adoptie van de cloud, focussen IT-managers zich op het vervangen van de datacenters en de besparing op de infrastructuur. Het development team focussen zich echter op de productiviteit en de mogelijkheden van de applicaties. Deze twee teams moeten echter vanaf het begin samenwerken om de uitdagingen die bij cloudadoptie komen kijken, te overwinnen. Zij moeten zichzelf vragen stellen als: hoe werkt de back-up? Hoe breiden we de bestaande beveiliging uit naar de cloud? En welk governance model hebben we in de cloud nodig? Ontdek meer over onze (cloud) security oplossingen.

5. Het ontbreken van FinOps expertise?

Wanneer we klanten helpen bij hun cloudstrategie en kijken naar hoe zij cloud en on-premise workloads combineren, zien we dat het hen vaak ontbreekt aan FinOps expertise, terwijl je juist daarmee een geavanceerd kosten- en inkoopscenario kunt creëren in een multi-cloud omgeving.

System Integrators en cloud architecten zijn meestal geen experts op het gebied van licenties. Zij houden zich niet bezig met de dynamische prijzen in de wereld van IT. Wil je bijvoorbeeld een licentie voor een database kopen, dan kun je deze rechtstreeks via een Marketplace kopen. Maar je kunt deze ook voordeliger aankopen via traditionele softwarecontracten met hybride rechten voor on-premise en de cloud. Bouw je een business case op in de veronderstelling dat je de software in de cloud aanschaft als SaaS-oplossing (wat aanneembaar is voor een architect), dan maak je op de verkeerde manier een inschatting van de IT uitgaven. We hebben al vaak gezien dat een business case niet werkt, omdat de softwarekosten worden overschat of juist onderschat. We zien dit ook gebeuren bij een cloud infrastructuur, waar langetermijncontracten vaak zorgen voor hoge kosten per unit.