Migratie van een SaaS-applicatie

Voor we het hebben over de mogelijkheden om over te stappen en eventuele obstakels en uitdagingen waarmee je te maken krijgt, is het belangrijk om te weten waarom je als SaaS ondernemer überhaupt over zou willen stappen naar een andere techparter. Arlon en ik komen daarbij samen tot een paar veelvoorkomende motivaties.

Zekeren van continuïteit

Wanneer je SaaS oplossing steeds succesvoller wordt, wordt ook de belasting van jouw ontwikkelaars groter. Wellicht heb je de oplossing in huis ontwikkeld, of samen met één of enkele betrokken developers. Een goed uitgangspunt in de start-upfase. De basis is neergezet, maar nu de applicatie succesvol is, wordt ook het risico groter. Je komt nu in de opschaalfase. Waar leg je dan de verantwoordelijkheid voor de techniek van jouw oplossing? Welk risico loop je wanneer één van jouw developers stopt of geen tijd meer heeft?

Door de technische verantwoordelijkheid neer te leggen bij een grotere, stabiele en leveringszekere partner, krijg je zelf de ruimte om te focussen op sales en marketing van je oplossing. Iets wat in deze nieuwe fase van jouw SaaS-oplossing belangrijk is. Het voordeel is bovendien dat alle expertise op gebied van code, veiligheid, privacy en scope aanwezig is bij een goede techpartner. Hierdoor kom je samen sneller verder en ben je verzekerd van continuïteit van je oplossing.

De stappen om over te stappen.

Wanneer je als SaaS-ondernemer besluit over te stappen, wil je dat dit zorgvuldig gebeurt. En liefst maar één keer. Daarom is de selectie van een goede partner essentieel. Hier komen we later op terug. Eerst vertelt Arlon wat er technisch nodig is om een migratie succesvol te laten verlopen.

Optie 1: De huidige applicatie is afgeschreven.

‘Dit is de meest extreme uitkomst. De code is bijvoorbeeld verouderd, of is niet geschikt om op grotere schaal toe te passen. In zo’n geval zal de nieuwe partner een voorstel doen om te herbouwen. Dit kan in één keer, of modulair. In dat laatste geval koppel je nieuwe modules aan de oude applicatie, die stuk voor stuk delen van de oude applicatie vervangen. Zodra alle delen vervangen zijn, kun je voorgoed afscheid nemen van de oorspronkelijke versie van je SaaS en heb je een gloednieuwe, schaalbare oplossing in handen.’

Optie 2: Een goede basis, met achterstallig onderhoud

‘Soms blijkt bij een code assessment dat de basis van een applicatie goed is om op voort te bouwen, maar dat de huidige kwaliteit te laag is. Meestal komt dit omdat de oplossing jouw ontwikkelaars al een tijdje boven het hoofd gegroeid is en er te weinig tijd of capaciteit was om onderhoud te doen. In zo’n geval wordt meestal een plan opgesteld voor de doorontwikkeling van de huidige applicatie, naast een plan voor het inhalen van achterstallig onderhoud. Liefst zou een developer uiteraard eerst al het onderhoud doen, alvorens verder te bouwen, maar met de bedrijfsdoelstellingen in het achterhoofd is dat vaak niet realistisch. Samenwerking met de oude ontwikkelaars is hier een mogelijke keuze. Waar de nieuwe partij start met de ontwikkeling van nieuwe functies voor toekomstige groei, richt de oude partij zich dan nog puur op het onderhoud.’

Optie 3: De huidige oplossing is in goede staat

‘De mooiste uitkomst van een code assessment, is wanneer de oplossing in goede staat verkeert. In zo’n geval kan je snel vervolgstappen plannen en is er minimaal onderhoud nodig om verder te gaan met het uitbouwen, verbeteren en vergroten van de oplossing.’

Zodra het plan staat, wordt met de voorbereidingen gestart. Het hangt van de hosting af of een applicatie ook fysiek verhuisd moet worden. Wanneer gebruik wordt gemaakt van cloud hosting via Kubernetes is fysieke migratie bijvoorbeeld niet altijd nodig, maar bij traditionele hosting is dit wel het geval en zal een nieuwe server ingericht moeten worden.

Binnen een OAP-omgeving wordt een testomgeving ingericht voor de applicatie. Deze omgeving dient ervoor om te testen of jouw SaaS overeind blijft na migratie. Hier kunnen gelijk de noodzakelijke aanpassingen gedaan worden om te zorgen dat jouw SaaS na de overstap normaal blijft functioneren. Wanneer alles klopt, wordt het overzetten naar de productieomgeving gepland, oftewel de livegang. Als alle voorbereidingen goed zijn getroffen, duurt dat omzetten vaak maar een kwartier, al is dat natuurlijk afhankelijk van de complexiteit en grootte van jouw SaaS.’

Wanneer is overstappen een probleem?

Er zijn een aantal zaken die het lastig kunnen maken om over te stappen, wanneer je deze niet vooraf goed hebt geregeld. Allereerst is er de juridische kant van SaaS, waarover ik voor Succes in Saas eerder sprak met advocaat en SaaS-ondernemer Maurits Geelkerken. Zorg vanaf de allereerste ontwikkeling dat je het intellectueel eigendom van je oplossing goed hebt vastgelegd, zodat je niet vastzit aan de ontwikkelaars die het gebouwd hebben. Door dit vast te leggen in de contracten met je ontwikkelaars, zorg je dat je de migratie-optie altijd openhoudt en niet klem komt te zitten in juridisch getouwtrek.

Een andere lastigheid kan het gebrek aan tijd of geld zijn. Hoe goed een nieuwe partner ook is: deze zal altijd tijd nodig hebben om jouw ambities en oplossing te leren kennen. Dit vraagt ook om een tijdsinvestering van jouw kant. Doorontwikkelen van een applicatie vraagt bovendien om een financiële investering. Deze betaalt zich op termijn uit, maar zonder eigen geld, of betrokken investeerders loop je vast. Wil je meer weten over het aantrekken van investeerders voor jouw SaaS, lees dan vooral het Succes in SaaS-artikel met investeerder Reinder Lubbers terug.

Tot slot is de code een mogelijke drempel om over te stappen, zo vertelt Arlon: ‘De programmeertaal bepaalt welke ontwikkelaars kunnen werken met jouw oplossing. Mijn advies is altijd om voor een universele taal te kiezen die veel gebruikt wordt in de wereld. Bijvoorbeeld PHP en Javascript. Veel programmeurs kennen deze talen en kunnen dus ook aan jouw oplossing werken. Maak hierin al bij de start een goede keuze. Uiteraard hoef je als SaaS-ondernemer de oplossing niet zelf te bouwen, maar door je goed te laten informeren over de standaarden die jouw developers gebruiken, weet je ook hoe flexibel je bent om andere developers in te schakelen voor de verdere ontwikkeling van jouw oplossing.’