SaaS-migratie in de praktijk: overstappen zonder een werkdag te verliezen

Een SaaS-migratie klinkt op papier als exporteren, importeren en de oude omgeving uitzetten. Zodra de dagelijkse operatie geen dag kan missen, valt dat behoorlijk tegen. Een handelsbedrijf dat orders verwerkt, een bureau dat uren schrijft of een uitgever die abonnementen beheert kan niet twee weken improviseren. Het vervangen van de applicatie is dan zelden het moeilijkste deel. Dat zit in de data, de koppelingen, de rechten en in alle uitzonderingen die er in de loop van de jaren ongemerkt bij zijn gekomen.

Daarom hieronder een praktijkvoorbeeld in plaats van een stappenplan. Het gaat om een Nederlandse organisatie met ongeveer 85 medewerkers die acht jaar lang met dezelfde cloudapplicatie werkte voor klantbeheer, projectplanning en facturatie. De tarieven liepen op, de API was te beperkt om fatsoenlijk mee te koppelen en elke maandrapportage werd met de hand uit een paar exports in elkaar geplakt. De directie wilde naar een moderner platform, maar niet ten koste van de historie, de omzet of het geduld van de eigen mensen.

Het probleem zat niet in de software

Op papier was de overstap overzichtelijk. Er lag een keuze voor een nieuw pakket, gebruikers aanmaken kostte een middag en de nieuwe leverancier had een importfunctie voor klanten en projecten. Alleen was het oude systeem in acht jaar tijd met de rest van het bedrijf vergroeid.

Klantgegevens kwamen binnen via formulieren op de website. Projectinformatie werd doorgezet naar een interne planningstool. Finance had een koppeling met het boekhoudpakket. Accountmanagers hadden zelf velden aangemaakt voor contractafspraken, prijsafspraken en verlengdata. Daarbovenop lagen er honderden lopende projecten, een flinke stapel dubbele klantrecords en documenten die aan een dossier moesten blijven hangen zonder dat ze per se mee hoefden naar het nieuwe platform.

De eerste vraag was dus niet of de data eruit te krijgen was. Die vraag was: welke processen moeten maandagochtend om half negen aantoonbaar werken? Dat verschil bepaalt of je een technische klus doet of een verandertraject begeleidt.

Eerst uitzoeken hoe er echt gewerkt wordt

Voordat er iets gebouwd werd, hebben we de bestaande situatie uitgeplozen. Niet alleen de database, ook het werk zoals mensen het feitelijk deden. Dat leverde meteen dingen op die in geen enkele handleiding staan.

Verkoop bleek een vrij tekstveld te gebruiken voor informatie die eigenlijk gestructureerd hoorde te zijn, zoals opzegtermijnen. Finance corrigeerde bepaalde facturen rechtstreeks in het boekhoudpakket, waardoor het oude SaaS-systeem op die punten al jaren niet meer klopte. En de planningskoppeling haalde ieder uur netjes gegevens op, maar alleen als een specifiek veld exact goed was ingevuld. Wie dat veld vergat, zag zijn project simpelweg niet in de planning verschijnen. Daar had iedereen zich bij neergelegd.

Uit die inventarisatie kwam een migratiekaart: per gegevenssoort de beslissing om volledig over te zetten, eerst op te schonen en dan over te zetten, te archiveren of te laten staan. Elke integratie kreeg een eigenaar, een korte technische beschrijving en een testscenario. Administratief, dat wel. Maar zo voorkom je dat een essentiële koppeling pas na de livegang wordt ontdekt, meestal door de persoon die er het hardst last van heeft.

Bewuste keuze: niet alles ging mee. Afgesloten projecten van ouder dan vijf jaar werden als leesbaar archief bewaard. Dubbele contactpersonen zijn samengevoegd, ongebruikte velden verdwenen. De nieuwe omgeving werd daar sneller en een stuk overzichtelijker van.

Drie keer migreren voordat het echt telt

De technische aanpak bestond uit drie rondes: een proef met een beperkte set, een volledige repetitie met alle relevante gegevens, en pas na akkoord de echte overgang.

Bij die proef ging het niet alleen om aantallen. Natuurlijk moesten de klanten, projecten en facturen kloppen. Belangrijker was de samenhang. Hing ieder project nog aan de juiste klant? Stonden openstaande taken bij de juiste medewerker? Klopten de factuurregels na herberekening? En kwam een wijziging in het nieuwe systeem netjes aan in de boekhouding?

De eerste ronde legde een klassieker bloot. Door een verschil in tijdzone schoven datums op een deel van de records een dag op. Bij historische notities is dat hinderlijk, bij contracteinddata en facturatiemomenten is het onacceptabel. We hebben dat niet met de hand rechtgetrokken maar de importlogica aangepast, dezelfde set opnieuw geladen en opnieuw gecontroleerd. Handmatige correcties overleven de volgende import namelijk niet.

Dat is de hele reden dat een proefmigratie bestaat. Een import die zonder foutmelding doorloopt, is nog geen geslaagde migratie. De uitkomst moet ook bedrijfsmatig kloppen.

Koppelingen zijn geen bijzaak

Veel migraties lopen uit omdat integraties tot het laatst blijven liggen. Hier ging het om koppelingen met de website, het boekhoudpakket, de documentopslag en de interne planning. Elk met eigen authenticatie, eigen foutafhandeling en eigen aannames over hoe een veld gevuld hoort te zijn.

De websitekoppeling is in de repetitiefase parallel aangesloten. Nieuwe aanvragen werden een paar weken lang naar beide omgevingen gestuurd, zodat we konden vergelijken wat er aankwam zonder dat er ook maar één lead verloren ging. Voor de boekhoudkoppeling kozen we juist voor een harde knip: in het migratieweekend gingen er geen facturen de deur uit, en na de livegang liep één collega de eerste dagen alle transacties na.

Niet elke integratie hoefde opnieuw gebouwd te worden. De documenten stonden al in een aparte documentopslag, los van het oude SaaS-pakket. Die opslag bleef gewoon staan en het nieuwe platform verwijst per dossier naar de juiste map. Alles alsnog naar het nieuwe systeem tillen had het project weken langer gemaakt, terwijl de winst klein was. Zulke afwegingen mag je best maken, als je ze maar vastlegt.

Het weekend van de overstap

De definitieve migratie viel in een weekend. Vrijdag om vier uur ging de oude omgeving in alleen-lezen. Wijzigingen die daarna nog binnenkwamen, werden volgens een vooraf afgesproken werkwijze op een gedeelde lijst gezet. Daarna volgden de laatste export, de import en de controlelijst die er al lag.

Die controles waren concreet: aantallen records, omzettotalen, openstaande facturen, rechten per gebruikersgroep, werking van de belangrijkste formulieren en het volledig doorlopen van een testproject inclusief factuur. Ook hebben mensen uit verkoop, finance en operatie op zaterdagmiddag hun eigen dagelijkse handelingen in de nieuwe omgeving gedaan. Niet als vrijblijvende demo maar als acceptatietest, met aftekenen.

Maandagochtend kon iedereen aan de slag. Er kwamen vragen over gewijzigde schermen en over een nieuwe manier van werken, maar niets dat het werk blokkeerde. De lijst met weekendwijzigingen is die ochtend verwerkt en nagelopen. De oude applicatie bleef nog zes weken als alleen-lezen archief beschikbaar. Pas toen duidelijk was dat alles stabiel draaide, inclusief de eerste volledige factuurronde, is het contract met de oude leverancier opgezegd.

Wat het opleverde, en wat niet meteen goed ging

Het resultaat was meer dan een nieuw pakket. De organisatie had haar data en processen weer op één plek. Rapportages kwamen rechtstreeks uit het systeem in plaats van uit drie exports en een spreadsheet. Leads kwamen controleerbaar binnen. Medewerkers zagen alleen wat ze nodig hadden, en de financiële cijfers sloten aan op de boekhouding.

Perfect was het niet meteen. Een aantal rapportages is na de livegang herzien, omdat managers pas in het gebruik ontdekten welke uitsplitsing ze eigenlijk misten. Een deel van de gebruikers had extra uitleg nodig over de nieuwe workflow, en die uitleg hadden we achteraf beter vóór de livegang kunnen inplannen. Dat hoort erbij. Een migratie is geen moment, maar een overgangsperiode.

De grootste winst zat in de voorbereiding. Doordat processen, data en koppelingen vooraf serieus zijn genomen, bleef de technische overgang klein en saai. Saai is in dit vak een compliment. Het scheelt bovendien als ontwikkeling, integraties en hosting bij één partij liggen: dan is er één telefoonnummer als er iets moet worden bijgesteld, in plaats van drie leveranciers die naar elkaar wijzen.

Is jouw organisatie toe aan een migratie?

Een SaaS-migratie is de moeite waard als het huidige systeem groei afremt, handwerk veroorzaakt of je te afhankelijk maakt van één leverancier. Overstappen puur omdat er iets aantrekkelijkers op de markt staat, is zelden een goed idee. Kijk eerst naar de processen die het systeem ondersteunt, de kwaliteit van je gegevens en de systemen waarmee het moet samenwerken.

In een kleine, overzichtelijke omgeving is een standaardimport prima. Bij maatwerkprocessen, gevoelige gegevens, complexe API-koppelingen of harde eisen aan beschikbaarheid is een gefaseerde aanpak verstandiger. Dan wil je vooraf weten wie je belt als data niet aankomt, een koppeling omvalt of de livegang teruggedraaid moet worden.

De beste migratie voelt voor gebruikers nauwelijks als een project. Ze merken vooral dat het werk sneller gaat, dat de informatie klopt en dat problemen niet blijven liggen. Daar begint een systeem dat weer voor het bedrijf werkt in plaats van andersom.