Inleiding

Succesvol migreren naar de cloud (bijvoorbeeld naar AWS, Azure of Google Cloud) lijkt op het eerste gezicht voor veel organisaties heel aantrekkelijk. Veelgehoorde argumenten zijn dat er minder operationeel beheer is, het goedkoper kan zijn en er gebruikgemaakt wordt van de laatste technologie.

De op hoofdlijnen opgestelde businesscase laat al snel de voordelen zien, maar een cloudmigratie kan ook vragen opleveren. Hoe ziet het traject er daadwerkelijk uit? Zijn de applicaties wel ‘cloud-ready’ en kennen we ons eigen applicatielandschap wel voldoende om op voorhand een juiste inschatting te kunnen maken? Wat zijn de grootste uitdagingen gelet op de eisen met betrekking tot wet- en regelgeving, privacy en beschikbaarheid?

In dit artikel belichten wij welke lessen (‘lessons learned’) wij uit een aantal recente cloudmigraties hebben getrokken.

Cloudmigratie: wat zijn de drijfveren?

Het besluit om te migreren naar de cloud kan verschillende redenen hebben. Een deel van het IT-landschap is bijvoorbeeld aan vernieuwing toe vanwege oplopende kosten of een te lage beschikbaarheid. Vanuit de businessstrategie is het argument om meer op de toekomst voorbereid te zijn, want cloudplatformen bieden veel innovatieve mogelijkheden. De lage instapkosten en flexibiliteit van cloudplatformen zorgen ervoor dat organisaties wendbaarder worden en makkelijker kunnen innoveren. Ook een voordeel is dat de beveiliging van het platform up-to-date wordt gehouden door de cloudserviceprovider.

Er zijn overigens ook overwegingen om de migratie naar een cloudomgeving nog niet (volledig) in te zetten. Zo is een deel van de applicaties wellicht ongeschikt om in de cloud te laten functioneren, bijvoorbeeld vanwege een verouderd besturingssysteem of vanwege complexe integratievraagstukken, of laten eisen aan certificering en performance (latency) het niet toe. Opslag van data buiten de Europese Unie kan soms vanwege wettelijke eisen een drempel zijn om naar de cloud te gaan.

Afhankelijk van de drijfveren om naar de cloud te gaan, is het van belang een route uit te stippelen om de transitie naar de cloud in te zetten.

De route naar de cloud

In de praktijk zien wij dat organisaties veelal beginnen met een aantal proofs of concept (PoC’s). De uitdaging voor hen is om vervolgens naar een gestructureerde en organisatiebrede inzet van clouddiensten te gaan. Er zijn verschillende redenen voor die uitdaging:

1. het ontbreken van inzicht in de mogelijkheden van de cloud;
2. beperkt commitment vanuit het (IT-)management;
3. het ontbreken van heldere doelstellingen voor de inzet van clouddiensten;
4. het ontbreken van een goede governance- en sourcingstrategie voor clouddiensten.

Het goed kunnen uitvoeren van een cloudtransformatie vraagt om een gecontroleerde aanpak/route (zie figuur 1).

Figuur 1. KPMG cloud journey. [Klik op de afbeelding voor een grotere afbeelding]

Gebaseerd op onze ervaringen met recent uitgevoerde cloudmigraties leggen wij in dit artikel de nadruk op deze fasen: 2 – Cloud-readiness, 3 – Cloudvalidatie en 5 – Migratie naar de cloud. Wij zijn er hierbij van uitgegaan dat reeds is gekozen voor een strategie en ambitie (fase 1 – Cloudambitie) en dat daarbij ook de keuze voor de nieuwe organisatie (fase 4 – Ontwerp de cloud) is meegenomen.

We richten ons hier alleen op een migratie van het applicatielandschap van een on-premise omgeving naar een cloudomgeving, en op alle aspecten die daarbij komen kijken. Greenfieldomgevingen of volledige SaaS-omgevingen vragen om een andere aanpak, die laten we in dit artikel buiten beschouwing.

Cloud-readiness

Vaststellen waar de organisatie staat met betrekking tot een transitie naar de cloud, gebeurt in de fase Cloud-readiness. Dit geeft een gedetailleerd beeld van de huidige status en het volwassenheidsniveau en is daarmee het startpunt voor het plan.

In hoeverre de organisatie in staat is met het huidige applicatielandschap naar de cloud te migreren, hangt in grote lijnen af van de onderstaande facetten:

1. Is het complete applicatielandschap inzichtelijk met alle bijbehorende kenmerken?
2. Zijn de applicatie-eigenaren en overige stakeholders bekend?
3. Zijn de eisen met betrekking tot wet- en regelgeving (onder andere privacy) en data bekend?
4. In hoeverre zijn de applicaties technisch gereed om naar de cloud te migreren?

Analyse van het informatievoorzieningslandschap

Organisaties worden gekenmerkt door een heterogeen informatievoorzieningslandschap met applicaties met vele onderlinge en infrastructurele afhankelijkheden (microservices, interfaces, enterprise service bus) en dat ook nog vaak met externe partijen. Vaak zien wij bij aanvang van een migratie dat er slechts beperkt kennis is van applicaties (denk aan type applicatie, operatingsysteem, databases, functie, eigenaarschap, beheer, versie, koppelingen, toekomst et cetera). En als die kennis er wel is, is die vaak niet eenduidig vastgelegd in een CMDB of slechts deels vastgelegd in diverse Excel-sheets of databases.

Voor het maken van een goed migratieplan is kwalitatief goede informatie over het applicatielandschap nodig. Daarbij spelen de eisen en inrichting van businesscontinuïteit en 24/7 beschikbaarheid (ook in geval van calamiteiten) een belangrijke rol. Ook is het van belang de afspraken te kennen over downtime en onderhoudswindows en na te denken over de vraag of we bij voorkeur in het weekend of ‘s nachts migreren om zo de impact voor eindgebruikers minimaal te houden. En is de software überhaupt wel geschikt voor de cloud of moet er wellicht nieuwe software worden ontwikkeld of aangeschaft? Is het antwoord op deze laatste vraag ja, dan zal het meer tijd kosten voordat de mogelijke cloudmigratie kan plaatsvinden.

Een groot risico is dat wanneer de juiste informatie ontbreekt, de analyse van het informatievoorzieningslandschap wordt verschoven naar de daadwerkelijke uitvoering van de migratie. Tijdens de executie moet dan alsnog een diepgaande analyse worden uitgevoerd, vaak onder tijdsdruk. Dit kan leiden tot vertraging van het project.

Voor het maken van migratiekeuzes per applicatie gebruiken we het ‘6R-model’ van Amazon ([Bish10]). Dit model onderscheidt zes migratiestrategieën: Retire, Retain, Re-purchase, Re-host, Re-platform en Re-factor. Dit model hebben wij voor de volledigheid uitgebreid met een zevende R: de mogelijkheid tot Redesign (zie figuur 2).

Figuur 2. Bepalen van de migratiestrategie per applicatie. [Klik op de afbeelding voor een grotere afbeelding]

Het resultaat na toepassing van het model is een helder inzicht in de migratiestrategie voor het applicatielandschap. Tevens wordt hiermee inzichtelijk welke applicaties niet (denk hier bijvoorbeeld aan medische apparatuur of gecertificeerde meetapparatuur) in aanmerking komen voor een cloudmigratie en in het huidige landschap blijven (Retain) of worden uitgefaseerd (Retire). De ervaring laat zien dat er door deze analyse een realistisch beeld ontstaat over de (on)mogelijkheden.

Applicatie-eigenaren

De rol van de applicatie-eigenaar (de verantwoordelijke voor de applicatie en vaak ook een van de gebruikers) is cruciaal voor de migratie. Als eigenaar van de applicatie zal deze zijn goedkeuring moeten geven. Wanneer de eigenaar niet bekend is, zal de vraag opkomen wie dan accepteert of de applicatie nog naar behoren functioneert en of het bedrijfsproces geen hinder ondervindt van de overgang. In een sterk gereguleerde omgeving¹ (gereguleerd door wetgeving, certificering, eisen aan beschikbaarheid en privacy, et cetera) zal dit complex zijn omdat hier vaak meerdere partijen een rol in spelen.

Een belangrijke eerste stap is dan ook om – naast de IT-organisatie – ook de business mee te nemen in de migratieplannen. Een migratietraject dat voor de business geen meerwaarde oplevert maar wel ongemak en risico’s met zich mee kan brengen, heeft over het algemeen geen prioriteit. Toch is de betrokkenheid van de business cruciaal voor het slagen van de migratie. De applicatie-eigenaar kan inschatten wat de risico’s en afhankelijkheden zijn vanuit bedrijfsprocesoptiek.

Compliance met wet- en regelgeving

Wet- en regelgeving spelen ook op het gebied van de cloud een grote rol, zowel tijdens als na de migratie. Toezichthoudende instanties (zoals DNB (zie [DNB20]), AFM, Autoriteit Persoonsgegevens, NVWA) passen regels toe op het gebruik van de cloud.

Gereguleerde en gecontroleerde toegang tot gegevens is absolute noodzaak. Deze aspecten zullen met name in de nieuwe omgeving op de juiste manier moeten worden ingericht.

Ten aanzien van het migratieproces zullen er ‘spelregels’ worden afgesproken waar het migratieproces aan moet voldoen. Denk hierbij aan het verlenen en innemen van toegang tot de productieomgevingen wanneer deze geanalyseerd en gemigreerd worden of aan eisen aan de continue (referentiële) integriteit en beschikbaarheid van gemigreerde data.

Opslag van privacygevoelige gegevens – zoals medische gegevens – mag niet op een server buiten de Europese Unie plaatsvinden ([Brui19]). Zijn data wel geclassificeerd? Alle data moeten onder de loep worden genomen en worden geclassificeerd zodat kan worden bepaald welke data mogen worden opgeslagen in de cloud en welke niet. Welke data zijn gevoelig en welke zijn minder gevoelig? Het is belangrijk data kritisch te classificeren. Als deze naar een specifieke persoon te herleiden zijn, zijn dat al zeer vertrouwelijke data (bijzondere persoonsgegevens). Een instrument waarmee dit op voorhand kan worden beoordeeld en gemonitord, is de Data Protection Impact Assessment (DPIA), in Nederland ook wel gegevensbeschermingseffectbeoordeling (GEB) genoemd. Hierbij wordt in vier categorieën gekeken naar de risico’s en wordt hun mogelijke impact bepaald: Operationeel, Cliënt, Financieel, Reputatie.

Op basis van de bovenstaande aspecten kan een overall classificatie van het huidige applicatielandschap worden opgesteld en kan worden bepaald wat de passende aanpak is.

Cloudvalidatie

Wanneer er een goed beeld bestaat van de mogelijkheden om (delen van) het IT-landschap naar de cloud te verplaatsen, is het verstandig een validatie uit te voeren op de plannen. Een belangrijk onderdeel van deze validatie is het opstellen van een businesscase.

Businesscase

Een businesscase is vaak een belangrijk sluitstuk van de besluitvorming voor de keuze voor de cloud. Hierin komt alle verzamelde informatie samen over het bestaande landschap, de nieuwe cloudomgeving en de transitie daarnaartoe.

Een businesscase heeft vaak een sterk financiële insteek. Het financiële deel is een belangrijk onderdeel waarin de bestaande kosten worden vergeleken met de kosten in de cloudomgeving, inclusief een afschrijving op migratiekosten. In de praktijk zien we regelmatig dat de businesscase financieel ‘rond neutraal’ uitkomt: de kosten voor cloud zijn vergelijkbaar met de kosten voor on-premise, zelfs als je de kosten voor migratie meeneemt.

Toch is dat voor veel organisaties niet de doorslaggevende factor in een businesscase. In een goede businesscase wordt naast de financiële component ook de waarde voor de organisatie meegenomen. Het is mooi als die toegevoegde waarde financieel of anderszins kwantitatief wordt gemaakt, maar dat hoeft niet. In een cloudstrategie beschrijven organisaties waarom zij gebruik willen maken van de cloud. Daar worden vaak ambities als snelheid, flexibiliteit, innovatie, minder beheer et cetera genoemd. Ook helpt een cloudtransformatie bij het wegwerken van ‘technologische schuld’, achterstallig onderhoud in het IT-landschap, bijvoorbeeld verouderde hardware of software. Dit zijn de echt doorslaggevende factoren om voor een cloudmigratie te kiezen.

Het is van belang meerdere stakeholders aan boord te krijgen van een cloudmigratie. Behalve voor de IT-afdeling moet de toegevoegde waarde ook voor de organisatie worden aangetoond, moet duidelijk worden in hoeverre de cloudomgeving compliant is aan de relevante wet- en regelgeving en dient soms ook de toezichthouder geïnformeerd te worden. De businesscase is een middel om dit brede spectrum aan stakeholders inzicht te geven in de voor- en nadelen van een transformatie. Het inzichtelijk maken van de kosten én de kwalitatieve voordelen in begrijpelijke taal is daarbij van belang.

Figuur 3. Deze acht elementen mogen in een businesscase voor een cloudmigratie zeker niet ontbreken. [Klik op de afbeelding voor een grotere afbeelding]

(On)zekerheden in de businesscase

Ondanks dat voor aanvang van een transformatie vaak een gedegen transformatieplan wordt gemaakt, bestaan bij het opstellen van een businesscase nog onzekerheden. Deze worden pas gedurende de transformatie verder ingevuld. Er wordt in de businesscase daarom gewerkt met aannames. Hoe scherper de aannames kunnen worden geformuleerd, hoe zekerder de businesscase zal zijn. Voor de kosten gaat dit bijvoorbeeld over de benodigde performance, redundantie in systemen en verbindingen. Wat betreft de verwachte besparingen zou dit kunnen gaan over bijvoorbeeld de looptijd van contracten, reserveringen van servers en optimalisatie van resources. Deze zullen een sterke invloed hebben op de verwachte kosten.

Monitoring vanaf de start van een migratie

De toegevoegde waarde van een goede businesscase bestaat niet alleen tijdens de initiële keuze voor de cloud, maar ook daarna door het continu monitoren van de kosten en baten. Daarom adviseren wij om gedurende de uitvoering van het migratieprogramma een aantal keer een ‘herijking’ van de businesscase uit te voeren. Daarbij worden de aannames geactualiseerd en opnieuw doorgerekend en worden de reeds bekende kosten bijgewerkt.

Zo wordt gedurende het migratieprogramma het inzicht in de migratiemogelijkheden van het landschap duidelijker en zullen ongetwijfeld ook een aantal onverwachte aspecten optreden. Dit kan leiden tot onrust bij stakeholders. Door het herijken van de businesscase wordt duidelijk in hoeverre de verwachte businesscase nog kan worden gerealiseerd en waar eventueel bijsturen nodig is. Dit geeft stakeholders inzicht en kan eventuele onrust wegnemen.

Migratie naar de cloud

Wanneer is gebleken dat de organisatie klaar is om naar de cloud te migreren en de businesscase dit ondersteunt, kan de migratie naar de cloud starten. Maar hoe kan een migratie succesvol worden gerealiseerd wanneer een organisatie, bijvoorbeeld een ziekenhuis, de ‘winkel’ altijd open moet kunnen houden? En hoe kan ervoor worden gezorgd dat tijdens de migratie wordt voldaan aan alle gestelde richtlijnen en kwaliteitsaspecten en dat de migratie binnen het vooraf gestelde budget wordt voldaan?

Verschillende aspecten spelen een rol om de migratie zo succesvol mogelijk te laten verlopen. De meest relevante aspecten voor een migratietraject worden achtereenvolgens toegelicht:

1. randvoorwaarden;
2. besturing;
3. aanpak.

Randvoorwaarden

Ieder project kent randvoorwaarden die het succes bepalen, afhankelijk van de gekozen aanpak tijdens het project. De bekendste randvoorwaarden die gelden voor een project, zijn de beschikbaarheid van kennis en capaciteit en de relatie met aanverwante projecten. In het geval van een migratie naar de cloud zijn een aantal extra randvoorwaarden beschreven die van groot belang zijn voor het succes van het gehele project.

Scope

Voorafgaand aan de migratie naar de cloud is het meer dan ooit van belang om de scope van de migratie te bepalen. Het is belangrijk dat vooraf wordt afgestemd of een applicatie over kan gaan naar de cloud. Dit omdat niet alleen de organisatie zelf maar ook de klanten van de organisatie hiermee gemoeid zijn. In sommige gevallen kan het een zaak van leven of dood zijn als een applicatie uitvalt als gevolg van een migratie naar de cloud. Stem daarom van tevoren duidelijk de scope van de migratie af en communiceer die organisatiebreed. Zo kan tijdig geacteerd worden in het geval van een incorrecte vaststelling van de scope.

Betrokkenheid vanuit de organisatie

Breng in kaart welke stakeholders vanuit de organisatie betrokken dienen te worden en waar zij verantwoordelijk voor zijn. Zo wordt de juiste kennis en kunde vanuit de organisatie op tijd betrokken en kunnen vraagstukken ten aanzien van de migratie naar de cloud voorafgaand maar ook tijdens de migratie tijdig worden getoetst bij de juiste personen.

Voor organisaties die een maatschappelijk belang vervullen, is het des te meer van belang om tijdig betrokkenen op het gebied van (integrale) veiligheid en compliance te betrekken. Zo wordt te allen tijde geborgd dat de organisatie haar taak kan blijven vervullen en wordt tijdig advies ingewonnen of de gemaakte keuzes veilig en compliant zijn.

(Tijdelijk) beheer

Voorafgaand aan de migratie naar de cloud lijkt het beheer van de gehele cloudomgeving wellicht nog ver weg. Echter, vanaf het moment dat de eerste applicatie gemigreerd wordt naar de cloud, dient deze in een (tijdelijke) cloudbeheeromgeving te komen. Het beheer van de cloudomgeving dient daarom al vormgegeven te worden vanaf het moment dat de organisatie besluit de migratie naar de cloud daadwerkelijk in te zetten. Wanneer dit beheer goed is ingericht, zullen de risico’s voor de performance van applicaties in de cloud worden verlaagd. Dit kan ervoor zorgen dat gebruikers de eerste gemigreerde applicaties als positief ervaren en kan voorkomen dat er door een te late inrichting van het cloudbeheer onnodige twijfels ontstaan over de verdere cloudmigratie.

Beperken van afhankelijkheden

Hoewel het bewaken en eventueel beperken van afhankelijkheden een rol speelt bij alle projecten, is dit voor een migratie naar de cloud nog belangrijker. Hierbij is de organisatie er niet mee geholpen wanneer de migratie naar de cloud afhangt van vele andere (IT-)projecten. Dit verhoogt het risico op een misstap in de migratie, op vertraging in de migratie (vertraging van het geheel of een bepaalde applicatie) en op een mogelijke impact op de eindgebruiker.

Besturing

De migratie naar de cloud kan worden opgevat als een technische of IT-aangelegenheid waarin de business een geringe rol speelt. Zoals bij de randvoorwaarden al werd aangestipt, is de betrokkenheid van de business van belang. Dit vanwege de impact die het migreren van applicaties heeft op de bedrijfsprocessen van de organisatie. Daarmee wordt de business een belangrijke stakeholder in de gehele migratie. Business en IT zullen elkaar moeten vinden in het midden, waarbij ze gezamenlijk aan het roer staan van de cloudmigratie en eventuele problemen die zich voordoen ook in samenspraak oplossen. Op deze manier staat de organisatie niet voor verrassingen en wordt gezamenlijk de verantwoordelijkheid gevoeld voor de uitvoering en oplevering. Het is dan ook van belang om de besturing en communicatie niet alleen in te regelen vanuit IT maar ook vanuit de business.

Het bovenstaande staat in contrast met omstandigheden waarin de business de migratie naar de cloud delegeert aan de IT-organisatie. Hierbij gaat de business er onterecht van uit dat alle uitgangspunten, kaders, omstandigheden, specificaties en dergelijke op voorhand voorspelbaar en voldoende duidelijk zijn.

Naast de betrokkenheid van zowel business als IT bij de migratie, zorgt het gebruik van de juiste tooling ervoor dat de voortgang op elk moment kan worden gemonitord. Ook rapportages ten aanzien van de migratie naar de cloud kunnen op deze manier helder en duidelijk worden vormgegeven om de organisatie correct te informeren. Correcte informatie en tijdige communicatie hierover zijn van groot belang voor het draagvlak voor de migratie en voor het tijdig ingrijpen in het geval zich een probleem voordoet.

Migratie en uitvoering

Tijdens fase 2, Cloud-readiness, wordt per applicatie de migratiestrategie bepaald. In figuur 2 zijn deze zeven mogelijkheden al samengevat. We staan hier stil bij de migratiestrategieën die leiden tot de grootste impact.

• De Re-factor-migratiestrategie houdt in dat de gehele applicatie (deels) opnieuw wordt opgebouwd om in de cloud te landen, maar dat de functionaliteit van de applicatie gelijk blijft. Re-factor is daarom een separaat softwareontwikkelingstraject dat business en IT samen uitvoeren. De Redesign-strategie is nagenoeg hetzelfde als Re-factor. Het verschil tussen Redesign en Re-factor is dat voor de Redesign-optie de functionaliteit het startpunt vormt voor de migratie en niet de applicatie.
• De Re-purchase-migratieaanpak is als het ware een geheel selectietraject voor nieuw aan te schaffen applicaties waarbij een geschikt (SaaS-)alternatief uit de markt geselecteerd wordt ter vervanging van de functionaliteit van de applicaties. Re-purchase is daarom vaak een businessproject.
• De Re-host– en Re-platform-migratiestrategieën bouwen voort op de bestaande applicaties. Ze hebben een gestructureerd karakter nodig vanwege het feit dat bestaande applicaties worden verplaatst naar de cloudomgeving en daarmee mogelijk een risico vormen voor de continuïteit van de bedrijfsvoering. Hierbij zijn controle en traceerbaarheid van de activiteiten ten aanzien van de migratie van groot belang. Zoals eerder vermeld, is het raadzaam hierbij gebruik te maken van tooling zoals Azure DevOps of JIRA.

De migratiestrategieën Re-host en Re-platform worden gekenmerkt door nagenoeg eenzelfde uitvoering en stappen en leiden niet tot separate projecten zoals bij Re-factor of Re-purchase. De stappen die worden gezet tijdens de uitvoering van de migratie, zijn samengevat in figuur 4.

Figuur 4. Migratieaanpak uitgezet in stappen. [Klik op de afbeelding voor een grotere afbeelding]

Conclusie

In dit artikel hebben we de lessons learned uit een aantal migraties in de praktijk gedeeld die betrekking hebben op de verschillende aspecten van een migratie. Bij het uitvoeren van diverse recente trajecten is gebleken dat het toepassen van deze lessen leidt tot een grotere mate van succes van een cloudtransformatie. Het hebben van een gestandaardiseerde en beproefde methodiek helpt daarnaast voor de volledigheid van de analyses en de kwaliteit van de migratie. Gebruikmaken van de cloud is daarbij nooit een doel op zichzelf, maar zou altijd verbonden moeten zijn met concrete en meetbare waardecreatie, waarde die niet alleen voor en tijdens (vaak op papier) maar ook vooral na de migratie gecreëerd moet worden op het moderne platform.