cloudmigratie
scenario's

Wanneer pas je welke toe en wat zijn de kenmerken?

Migreren naar de cloud betekent keuzes maken. Verhuis je bestaande applicaties mee, bouw je ze opnieuw op in de cloud of vervang je ze door SaaS-oplossingen?En hoe maak je daarbij de juiste security en compliance afwegingen?

Hieronder kun je de kenmerken en voorwaarden van alle 8 migratiescenario’s teruglezen. Elke functionaliteit vraagt namelijk om andere aanpak en daarbij hoort ook een ander migratiescenario. 

Download hier de Solvinity migratiewijzer zodat jij voor jouw organisatie het juiste scenario kunt bepalen.

#1 Retire

De applicatie uitfaseren of ontmantelen

Soms is een legacy-applicatie niet langer nuttig. Bijvoorbeeld omdat hij niet of nauwelijks meer gebruikt wordt. Het uitschakelen van deze applicatie zorgt dan voor directe (kosten)besparingen: je hoeft geen (beheer)kennis meer vast te houden, potentiële security problemen vervallen en de applicatie neemt geen (opslag)ruimte meer in beslag op de on-premises server.

RETAIN

#2 Retain

De applicatie (voor nu) behouden

Migreren naar de cloud is niet altijd zinvol. Bijvoorbeeld als er sprake is van een ‘special’ (custom applicatie) met specifieke hardware of een (storage)systeem dat je niet zomaar mag verplaatsen. Ook is een cloudmigratie soms vanwege security redenen niet toegestaan of is de applicatie zo uniek of speciaal dat er (nog) geen SaaS variant is.

Let wel, het draaien van speciale applicaties is doorgaans kostbaar en risicovol. Dit komt mede omdat je de beheerkennis in huis moet hebben en houden. Wij adviseren om te blijven zoeken naar een (beter) alternatief. Evalueer regelmatig of een migratie op een bepaald moment wél mogelijk is. Er zullen echter gevallen blijven waarbij een cloudmigratie nooit een mogelijkheid wordt.

#3 Rebuild (of Re-architect)

De applicatie opnieuw ontwerpen en bouwen

Rebuild is vooral interessant voor organisaties die hun eigen strategische applicatie willen vernieuwen. Bijvoorbeeld omdat de applicatie een uniek concurrentievoordeel biedt, maar niet meer toekomstbestendig is door verouderde programming frameworks.

Je gaat de applicatie opnieuw bouwen. Dat kan bijvoorbeeld via microservices. Hiermee bouw je de software op aan de hand van kleine autonome services, die onderling communiceren via API’s. Omdat je de mini-applicaties afzonderlijk van elkaar kan beheren is er een minimum aan afhankelijkheden. Met de CI/CD-werkwijze kun je bovendien vrijwel alle stappen automatiseren.

Van alle migratiescenario’s is rebuilding de meest kostbare en risicovolle methode. Het is alsof je je huis sloopt en steen voor steen weer in elkaar zet, maar dan met de modernste bouwmaterialen. Hiervoor is veel expertise nodig – en een lange adem!

REFACTOR

#4 Refactor

De applicatie herstructureren met cloud native features

Bij refactoring bouw je de applicatie niet helemaal opnieuw, maar brengt stukje bij beetje verbeteringen aan. Je herstructureert als het ware secties van je applicatie. Door hierbij slim gebruik te maken van al bestaande services met cloud-native functionaliteiten, profiteert je verbeterde applicatie optimaal van de flexibiliteit die de cloud biedt. Dit kan veel tijd en middelen schelen. Ander voordeel is een verbeterde leesbaarheid van de code, waardoor deze efficiënter en beter te onderhouden is. Ook zijn er minder risico’s omdat je geleidelijke aanpassingen doet. Bovendien betaal je alleen voor wat je nodig hebt. 

Refactoring komt veel voor. Het is een eerste stap om de applicatie helemaal toe te snijden op een cloudomgeving. Maar ook om bijvoorbeeld van leverancier te switchen of van een dure server of (platform)service over te stappen naar een goedkopere (platform)service. Zoals bijvoorbeeld van Oracle naar SQL.

#5 Rehost

De service (met daarop je applicaties) van on-premises verplaatsen naar de cloud

Een eenvoudige manier om naar de cloud te migreren, is door je huidige omgeving op te pakken en deze ergens anders neer te zetten. Dit wordt ook wel een lift-and-shift genoemd. Je verplaatst je virtuele machine met daarop je applicatie naar de public cloudomgeving van bijvoorbeeld Amazon of Azure.  Dit vergt een paar kleine aanpassingen, maar geen grote wijzigingen in je architectuur. Eenmaal in de cloud kun je alsnog optimaliseren of herontwerpen met behulp van (cloud)resources.

Rehosting komt veel voor, bijvoorbeeld wanneer je onder significante tijdsdruk een on-premises omgeving moet afsluiten. Of als een cloudmigratie kritiek is voor bedrijfsgroei maar het developmentteam onvoldoende kennis heeft van cloud-native technieken. Omdat je applicaties zonder optimalisatieslag naar de cloud verplaatst, is rehosting niet ideaal. Wel is het een goede manier om kennis op te doen van het cloudplatform, de services en het abonnementsmodel. Vervolgens kun je kijken hoe je de huidige virtuele machines, software en services beter kan inzetten binnen het cloudlandschap.

RE-INSTALL

#6 Re-install

Je software opnieuw installeren op een nieuwe machine

Met deze strategie installeer je samen met de softwareleverancier opnieuw je software op een nieuwe (virtuele) machine in de cloud.  Dit is een slimme manier om bijvoorbeeld een verouderd besturingssysteem te updaten of over te stappen op een ander formaat softwarestack. Met de nieuwe softwareversie ben je direct compliant en beschik je over meer of snellere functionaliteiten.

Re-install is een duurdere migratiemethode dan bijvoorbeeld rehosting, maar komt vaak voor. Bijvoorbeeld omdat de klant een nieuwe versie van een besturingssysteem nodig heeft om compliant te blijven, waardoor ook de applicatie een update moet krijgen.

#7 Replatform

De huidige (fysieke of virtuele) machine vervangen door een service

Bij een replatform vervang je je huidige machine met een cloudservice, en neemt hierop een platformdienst af. Je stapt dus over naar een ‘Platform-as-a-Service’-model. Dit haalt veel complexiteit weg. Zo hoef je het besturingssysteem zelf niet meer te updaten of beheren. Dit doet de leverancier voortaan allemaal voor je. Een voorbeeld van een functionaliteit die draait op een platformdienst is een multi-factor authenticatie (MFA).

REPLACE

#8 Replace (of Repurchase)

De applicatie vervangen door een SaaS-applicatie

Door een nieuwe functionaliteit af te nemen als ‘Software-as-a-Service’, hoef je zelf niets meer te installeren of programmeren. Je wordt hierdoor afhankelijk van het aanbod van de softwareleverancier, maar ook volledig ontzorgd. De voordelen zijn dat je bijvoorbeeld minder kosten maakt voor de infrastructuur, onderhoud en de ontwikkeling van nieuwe functionaliteiten. Ook profiteer je van een snelle time-to-market en geniet een hoge mate van flexibiliteit.

Vaak biedt de service functionaliteiten op het gebied van CMS, HRM, CRM, accounting, rapportages, email en document sharing. Voorbeelden zijn Microsoft 365, Google Workplace, HubSpot of Zoom.

Advies nodig? Migreren naar de cloud is tenslotte niet iets wat je als organisatie dagelijks doet. Solvinity wel. Als specialist in het ontwerpen, bouwen en beheren van compliant en veilige IT-omgevingen, adviseren we je graag bij je cloudtransitie.

De Solvinity migratiewijzer aanvragen?

Kom alles te weten over de logica en opbouw om zelf het juiste scenario te bepalen
Elke functionaliteit vraagt tenslotte om een ander migratiescenario
Background Icon

Advies inwinnen voor je cloudtransitie?

Samen zorgen we ervoor dat je de beste én meest veilige migratiekeuze maakt.

Neem contact met ons op.
Background Icon