Nu hoeft dat in principe geen probleem te zijn, maar het is wel handig om de juiste stappen te nemen. Hoe soepel en eenvoudig dat gaat hangt sterk af van je omgeving, je applicaties en hoe deze nu al worden aangeboden aan eindgebruikers.

“Wie bijvoorbeeld een VM-ware-omgeving draait en de boel overbrengt naar een cloud-aanbieder die dat ook doet, dan is het heel eenvoudig om dat uit te voeren zonder enige downtime", zegt Michael Pauly, cloudcomputingspecialist bij T-Systems, de ict-tak van Deutsche Telekom. “Bij een niet-gevirtualiseerde omgeving hoeft het overbrengen ook niet zo moeilijk te zijn, maar moet je wel rekenen op enige downtime."

De basisstappen die volgen gaan dan ook uit van een situatie dat het om twee verschillende soorten omgevingen gaat. Vanaf het begin is het volgens Pauly handig niet zozeer in losse applicaties of zelfs architecturen te denken, maar in processen.

Stap 1: Weet wat je kunt en wilt verhuizen

Zelden zul je alle onderdelen afstoten naar een externe provider, dus je zult keuzes moeten maken. Het ene systeem is nou eenmaal beter geschikt om via een cloud te worden aangeboden dan een ander systeem. Technische overwegingen zijn maar een klein deel van de analyse. “Sommige processen mag je contractueel of juridisch helemaal niet naar buiten plaatsen", zegt Pauly.

Stap 2: Groepeer systemen in pakketten

Als je eenmaal weet wat je ongeveer wil overhevelen, begint het te dagen waarom het praktisch is in processen te denken. “Systemen communiceren nou eenmaal met andere systemen, dus dat moet je allemaal meenemen in de overheveling."

Als applicatie A wel naar de cloudaanbieder gaat, maar sterk afhankelijk is van de onbeweegbare database B, dan kan bijvoorbeeld latency roet in het eten gooien. “Mocht het niet mogelijk zijn om één van die twee systemen over te dragen, dan heeft het dus uiterst weinig zin om dat wel met het andere systeem te doen. Ook al is dat andere systeem in principe nog zo geschikt daarvoor."

Stap 3: Zorg dat de organisatie er klaar voor is

Het is naïef te denken dat na de verhuizing voor de afdelingen alles hetzelfde voelt. Nog voordat het allemaal wordt doorgevoerd. moeten de interne processen binnen de organisatie worden aangepast, aldus Pauly. “Ze krijgen te maken met een hele andere dynamiek", zegt hij. “Een webserver of een trainingssysteem kun je bijvoorbeeld in de cloud slechts voor de tijd afnemen dat je het nodig hebt. Je kunt het vervolgens weghalen, of ergens op langetermijnsstorage laten zetten. Het is allemaal een stuk flexibeler."

Voordelig of niet, je zult toch je processen op die nieuwe situatie aan moeten passen. “Het plannen van projecten gaat voor afdelingen meer een ad-hoc karakter krijgen." Een marketingafdeling zal volgens Pauly anders moeten nadenken over campagnes, waarbij de 'tijdelijke' mogelijkheden meer in het oog worden gehouden. “Ook zul je moeten vastleggen wie toegang krijgt tot welke diensten, en wat ze precies mogen als het gaat om uitbreiden. Ligt de uiteindelijke beslissing bij de hoofd van die afdeling, hoofd ict, of zelfs bij individuele werknemers? Waar komt de controle te liggen?"

Stap 4: Dan eindelijk: verhuizen

Als dat allemaal is geregeld, vastgelegd, bediscussieerd en/of uitgeruzied, kun je eindelijk daadwerkelijk gaan verhuizen. Dat doe je pakket voor pakket, alsof je de systemen die bij elkaar horen in dezelfde verhuisdoos hebt gepropt. Het is dus een kwestie van dat je weet in welke volgorde je de systemen opstart. Als het goed is heb je dat ook goed overzichtelijk gemaakt.

Hoe je downtime kunt vermijden hangt volgens Pauly sterk af van wat je uiteindelijk verhuist. “Afhankelijk van de applicatie moet je deze op eigen locatie stopzetten en in de cloud opstarten, of moet je het gewoon beginnen met draaien en de gegevens synchroniseren", zegt Pauly. “In de meeste gevallen is het mogelijk om downtime te beperken tot hooguit een paar minuten."

Het klinkt allemaal heel simpel, “maar het is allemaal redelijk complex. Je hebt met heel veel mensen te maken, en dat maakt het moeilijk. De complexiteit zit echt niet in de techniek."