Niet elke applicatie is geschikt voor de cloud, en niet elke applicatie hoort on-premise te blijven. De sleutel ligt in een gestructureerde beoordeling van elke applicatie op technische, financiële en organisatorische criteria. Voor middelgrote en grote organisaties met complexe IT-omgevingen is die afweging zelden eenvoudig, maar wel cruciaal om te voorkomen dat een cloudmigratie uitloopt op hogere kosten of operationele problemen. In dit artikel beantwoorden we de meest gestelde vragen rondom cloud readiness, applicatieportfolio-analyse en de keuzes die daarbij komen kijken.
Welke criteria bepalen of een applicatie geschikt is voor de cloud?
Een applicatie is geschikt voor de cloud als deze voldoet aan een combinatie van technische, operationele en strategische criteria. De belangrijkste factoren zijn: de mate van standaardisatie van de applicatie, de afhankelijkheden met andere systemen, de schaalbaarheid van de werkbelasting, de gevoeligheid van de data en de totale eigendomskosten in vergelijking met een cloudoplossing.
Concreet kun je bij elke applicatie de volgende vragen stellen:
- Technische geschiktheid: Draait de applicatie op verouderde infrastructuur of is ze al gebouwd op moderne architectuurprincipes? Hoe complex zijn de integraties met andere systemen?
- Schaalbaarheid: Is de vraag naar de applicatie wisselend of stabiel? Cloud is met name voordelig als de belasting fluctueert.
- Dataclassificatie: Bevat de applicatie persoonsgegevens of bedrijfsgevoelige informatie waarvoor strikte locatie-eisen gelden?
- Licentiestructuur: Laat de huidige softwarelicentie cloudgebruik toe, of leidt migratie tot extra licentiekosten of complianceproblemen?
- Businesswaarde: Ondersteunt de applicatie een kernproces, of is het een randapplicatie met beperkte strategische relevantie?
Cloud readiness is geen binaire keuze. Sommige applicaties zijn direct klaar voor migratie, andere vereisen aanpassingen en sommige horen gewoon niet in de cloud thuis.
Grip op uw IT-contracten en kosten?
Onze experts helpen u met IT-sourcing, contracten, licenties en kostenoptimalisatie.
Wat zijn de meest gebruikte methoden voor applicatieportfolio-analyse?
De meest gebruikte methoden voor applicatieportfolio-analyse zijn het 6R-model (Retire, Retain, Rehost, Replatform, Refactor, Repurchase), de Gartner TIME-methode en op maat gemaakte scorecards op basis van technische en zakelijke criteria. Elk model helpt organisaties om hun applicatielandschap systematisch te beoordelen en migratiebeslissingen te prioriteren.
Het 6R-model
Het 6R-model is de meest gangbare aanpak bij cloudmigraties. Het deelt applicaties in zes categorieën in:
- Retire: Applicaties die niet langer nodig zijn en kunnen worden uitgezet.
- Retain: Applicaties die voorlopig on-premise blijven vanwege technische of zakelijke redenen.
- Rehost (lift-and-shift): Applicaties die zonder aanpassingen naar de cloud worden verplaatst.
- Replatform: Applicaties die met beperkte aanpassingen profiteren van cloudmogelijkheden.
- Refactor: Applicaties die grondig worden herschreven om cloud-native te worden.
- Repurchase: Applicaties die worden vervangen door een SaaS-oplossing.
De Gartner TIME-methode
De TIME-methode (Tolerate, Invest, Migrate, Eliminate) richt zich meer op de zakelijke en strategische waarde van applicaties. Het is een nuttige aanvulling op technische analyses, omdat het de koppeling legt tussen IT-portfolio en bedrijfsdoelstellingen. Organisaties die een breed applicatielandschap beheren, combineren beide modellen vaak voor een completer beeld.
Welke applicaties kun je beter on-premise houden?
Applicaties die je beter on-premise kunt houden zijn systemen met strikte data-soevereiniteitseisen, sterk verouderde architectuur zonder cloudpad, zeer lage en stabiele werkbelasting waarbij cloud geen kostenvoordeel biedt, of applicaties met complexe licentiestructuren die cloudgebruik duur of juridisch problematisch maken.
Specifieke voorbeelden zijn:
- Applicaties die werken met staatsgeheimen of bijzonder gevoelige persoonsgegevens waarvoor de locatie van dataopslag wettelijk is vastgelegd.
- Maatwerksystemen die zo diep verweven zijn met on-premise infrastructuur dat migratie een volledige herbouw vereist zonder duidelijk zakelijk voordeel.
- Systemen met real-timevereisten en extreem lage latentie, waarbij cloudconnectiviteit een bottleneck vormt.
- Applicaties waarvan de leverancier cloudgebruik niet ondersteunt of waarvoor aanvullende licentiekosten de businesscase negatief maken.
Het behouden van applicaties on-premise is geen teken van achterstand. Het is een bewuste strategische keuze op basis van feiten, niet van gewoonte.
Hoe bereken je de totale kosten van cloudmigratie per applicatie?
De totale kosten van cloudmigratie per applicatie bereken je door de migratiekosten zelf, de lopende cloudkosten na migratie en de indirecte kosten zoals licentieaanpassingen, training en integratiewerk op te tellen en te vergelijken met de huidige eigendomskosten. Dit wordt ook wel de Total Cost of Ownership (TCO)-analyse genoemd.
Een volledige TCO-berekening omvat:
- Eenmalige migratiekosten: Projectkosten, externe expertise, herarchitectuur en testfasen.
- Structurele cloudkosten: Compute, opslag, netwerk, licenties en beheerkosten bij de cloudprovider.
- Licentie-impact: Sommige on-premise licenties zijn niet overdraagbaar naar de cloud zonder extra kosten. Dit geldt met name voor Oracle, SAP en Microsoft in specifieke configuraties.
- Operationele kosten: Interne beheercapaciteit, monitoring en support na migratie.
- Verborgen kosten: Data-egresskosten, downtime tijdens migratie en eventuele rollback-scenario’s.
Veel organisaties onderschatten met name de licentie-impact en de data-egresskosten. Een reële businesscase vraagt om een gedetailleerde analyse per applicatie, niet om een generieke schatting op portfolioniveau.
Wat is het verschil tussen lift-and-shift en cloud-native migratie?
Lift-and-shift betekent dat een applicatie zonder aanpassingen wordt verplaatst naar de cloud, terwijl cloud-native migratie inhoudt dat de applicatie wordt herschreven of herontworpen om volledig gebruik te maken van cloudmogelijkheden zoals automatisch schalen, microservices en serverlessarchitectuur.
Beide benaderingen hebben specifieke voor- en nadelen:
- Lift-and-shift is snel en relatief goedkoop om uit te voeren, maar levert beperkte cloudvoordelen op. De applicatie draait in de cloud, maar gedraagt zich als een on-premise systeem. Kostenoptimalisatie is daarna vaak nog een aparte stap.
- Cloud-native migratie vraagt meer tijd, budget en technische kennis, maar levert structureel hogere flexibiliteit, betere schaalbaarheid en lagere operationele kosten op de lange termijn.
De juiste keuze hangt af van de strategische relevantie van de applicatie, het beschikbare budget en de gewenste snelheid van migratie. Voor niet-kritieke applicaties is lift-and-shift vaak voldoende. Voor strategische kernprocessen loont een cloud-native aanpak doorgaans beter.
Hoe voorkom je dat cloudmigratie leidt tot hogere IT-kosten?
Je voorkomt hogere IT-kosten na cloudmigratie door vooraf een realistische TCO-analyse te maken, licentieconsequenties in kaart te brengen, cloudverbruik actief te monitoren en een FinOps-aanpak te implementeren die kostenverantwoordelijkheid belegt bij de teams die de kosten ook maken.
De meest voorkomende oorzaken van kostenstijging na migratie zijn:
- Overprovisioning: meer cloudcapaciteit inkopen dan daadwerkelijk nodig is.
- Ongebruikte resources die blijven draaien zonder dat iemand dit opmerkt.
- Licentiekosten die onverwacht hoger uitvallen doordat on-premise licenties niet geldig zijn in de cloud.
- Gebrek aan governance: geen duidelijk eigenaarschap over clouduitgaven per team of applicatie.
- Data-egresskosten die bij migratieplanning niet zijn meegenomen.
Een FinOps-aanpak helpt organisaties om cloudkosten continu te monitoren en bij te sturen. Dit is geen eenmalige actie, maar een doorlopend proces van meten, analyseren en optimaliseren. Cloudkosten zijn variabel van aard en vragen daarom ook een variabele, actieve beheeraanpak.
Wanneer is externe expertise nodig bij een cloudportfoliobeslissing?
Externe expertise is nodig bij een cloudportfoliobeslissing zodra de interne kennis over leverancierscontracten, licentiestructuren of cloudarchitectuur onvoldoende is om een gefundeerde keuze te maken, of wanneer de financiële impact van een verkeerde beslissing groot genoeg is om externe expertise te rechtvaardigen.
Concrete situaties waarin externe ondersteuning meerwaarde biedt:
- Bij grote contractverlengingen waarbij cloudmigratie de licentiekosten bij leveranciers zoals Oracle, SAP of Microsoft significant beïnvloedt.
- Wanneer een leverancier een compliance-claim of licentie-audit aankondigt rondom cloudgebruik.
- Bij het beoordelen van outsourcing- of cloudcontracten waarbij de kennisongelijkheid met de leverancier groot is.
- Als de interne IT-afdeling de capaciteit mist om een volledige applicatieportfolio-analyse uit te voeren naast de dagelijkse operatie.
- Wanneer een cloudmigratie onderdeel is van een bredere strategische verandering zoals een fusie, overname of grootschalige digitale transformatie.
Hoe Thornstein Groep helpt bij cloudportfoliobeslissingen
Wij begrijpen dat de keuze welke applicaties wel of niet naar de cloud gaan, zelden alleen een technische beslissing is. Het raakt aan contracten, licenties, leveranciersrelaties en financiële risico’s die samen de businesscase bepalen. Vanuit onze onafhankelijke positie helpen wij organisaties bij:
- Het uitvoeren van een gestructureerde applicatieportfolio-analyse op basis van technische en zakelijke criteria.
- Het in kaart brengen van licentie- en contractrisico’s bij cloudmigratie, inclusief de impact op overeenkomsten met leveranciers zoals Microsoft, Oracle en SAP.
- Het opzetten van een reële TCO-berekening per applicatie, zodat de businesscase op feiten is gebaseerd.
- Het implementeren van een FinOps-aanpak die cloudkosten beheersbaar houdt na migratie.
- Het versterken van uw onderhandelingspositie bij leveranciers, zodat u betere commerciële voorwaarden bedingt voor cloud- en softwarecontracten.
Wilt u weten waar uw organisatie staat en welke applicaties wel of niet naar de cloud moeten? Neem vrijblijvend contact met ons op voor een oriënterend gesprek.
Veelgestelde vragen
Hoe lang duurt een volledige applicatieportfolio-analyse gemiddeld?
De doorlooptijd van een applicatieportfolio-analyse hangt sterk af van de omvang en complexiteit van het applicatielandschap. Voor middelgrote organisaties met 50 tot 150 applicaties rekent u doorgaans op vier tot acht weken, inclusief interviews met applicatie-eigenaren, technische beoordeling en het opstellen van een migratieprioritering. Grotere organisaties met honderden applicaties en meerdere bedrijfsonderdelen kunnen zes maanden of meer nodig hebben voor een volledige analyse. Het loont om de analyse gefaseerd aan te pakken: begin met de applicaties die de grootste strategische of financiële impact hebben.
Wat zijn veelgemaakte fouten bij het toepassen van het 6R-model?
Een veelgemaakte fout is dat organisaties het 6R-model puur technisch invullen zonder de zakelijke context mee te wegen, waardoor applicaties worden gemigreerd die strategisch gezien beter vervangen of uitgezet hadden kunnen worden. Een andere veelvoorkomende misstap is het standaard kiezen voor ‘Rehost’ omdat dit de snelste optie lijkt, zonder te onderzoeken of een ‘Replatform’ of ‘Repurchase’ op de middellange termijn meer oplevert. Gebruik het 6R-model altijd in combinatie met een TCO-analyse en een zakelijke prioritering om te voorkomen dat u snel migreert maar structureel duurder uit bent.
Hoe ga je om met applicaties waarvan de leverancier geen duidelijkheid geeft over cloudondersteuning?
Als een leverancier geen duidelijke uitspraken doet over cloudondersteuning, is het verstandig dit contractueel te laten vastleggen vóórdat u migreert. Vraag expliciet naar de supportpositie van de leverancier bij cloudgebruik, de licentiegeldigheid in een cloudomgeving en eventuele aanvullende kosten. Ontbreekt die duidelijkheid, dan is migratie een risico: u kunt buiten support terechtkomen of onverwacht extra licentiekosten krijgen. In dat geval is het raadzaam externe expertise in te schakelen die de leverancierscontracten beoordeelt en uw onderhandelingspositie versterkt.
Kun je een cloudmigratie terugdraaien als de kosten of prestaties tegenvallen?
Technisch gezien is een cloudmigratie terugdraaien mogelijk, maar in de praktijk is het complex, tijdrovend en kostbaar. Data moet worden teruggeplaatst naar on-premise infrastructuur, configuraties moeten worden aangepast en data-egresskosten komen daarbij kijken. Bovendien is de on-premise infrastructuur in veel gevallen al afgebouwd of overgedragen. Voorkom deze situatie door vóór de migratie een duidelijk rollback-scenario op te stellen, pilotmigraties te doen voor kritieke applicaties en prestatie- en kostendrempels te definiëren waarop u actief monitort.
Wat is het verschil tussen een private cloud en een public cloud, en wanneer kies je voor welke?
Een public cloud, zoals Microsoft Azure, AWS of Google Cloud, is gedeelde infrastructuur die wordt beheerd door een externe cloudprovider en die u op verbruiksbasis afneemt. Een private cloud is dedicated infrastructuur die uitsluitend voor uw organisatie wordt gebruikt, on-premise of in een co-locatiefaciliteit. U kiest voor een private cloud wanneer strikte data-soevereiniteitseisen, complianceverplichtingen of extreem lage latentievereisten een gedeelde omgeving uitsluiten. Voor de meeste bedrijfsapplicaties biedt een public cloud echter voldoende beveiliging en meer flexibiliteit tegen lagere beheerkosten.
Hoe betrek je interne stakeholders bij cloudportfoliobeslissingen zonder dat het proces vastloopt?
Cloudportfoliobeslissingen raken meerdere afdelingen tegelijk: IT, finance, legal, inkoop en de business. Zorg voor een heldere besluitvormingsstructuur met één eigenaar per applicatie en een stuurgroep die knopen doorhakt op portfolioniveau. Gebruik gestructureerde scorecards zodat beoordelingen objectief en vergelijkbaar zijn, in plaats van afhankelijk van individuele voorkeuren. Beperk de besluitvorming per applicatie tot de criteria die er echt toe doen en vermijd eindeloze discussies over details door vooraf duidelijke drempelwaarden te definiëren voor migratie, behoud of uitfasering.
Wanneer is een hybride cloudstrategie de beste keuze?
Een hybride cloudstrategie, waarbij een deel van de applicaties on-premise blijft en een deel naar de public cloud gaat, is de beste keuze voor organisaties die te maken hebben met uiteenlopende eisen per applicatie. Denk aan een combinatie van sterk gereguleerde systemen die on-premise moeten blijven en flexibele bedrijfsapplicaties die juist baat hebben bij cloudschaalbaarheid. Een hybride aanpak vraagt wel om een doordachte integratielaag en duidelijke governance, anders neemt de complexiteit toe zonder dat u de voordelen van beide werelden volledig benut. De applicatieportfolio-analyse is het fundament om te bepalen welke applicaties waar thuishoren.
