Overstappen op Open Source – De tips

Steeds meer bedrijven zien het voordeel van het gebruik van open source software in hun IT-landschap. Niet alleen vanwege het feit dat het licentie-vrij is, maar ook door de beschikbaarheid van de broncode waardoor zelf aanpassen mogelijk is. Toch wordt er te makkelijk gedacht over het overstappen naar open source software. Het migreren van bijv. een Microsoft product naar een open source product is niet iets wat je zomaar even doet. Dit vergt de nodige voorbereiding maar ook kennis van beide producten. En daar gaat het vaak fout. Gebrek aan kennis van één van beide producten kan ervoor zorgen dat de migratie mislukt en dat een bedrijf bij het oude product blijft. Maar waar moet nou eigenlijk op gelet worden bij de overstap naar open source? 

Oriëntatie 
Er zijn veel aanbieders en veel varianten van open source. Bij de overstap van een bestaand product dienen niet alleen de huidige functionaliteiten goed beschreven te zijn, maar ook de eisen van het nieuwe product. Zijn bijvoorbeeld alle huidige functionaliteiten ook echt allemaal nodig in het nieuwe product? Of zijn er extra functionaliteiten nodig? Wanneer er een duidelijke lijst met wensen en eisen is gemaakt, zal dit de zoektocht naar het juiste open source product makkelijker maken. 

Kennis
Om te bedenken hoe en door wie de overstap uitgevoerd wordt, waar de ondersteuning ligt en hoe het beheer geregeld wordt, is het belangrijk om te kijken naar de benodigde kennis. Bij een migratie van Microsoft naar open source is een IT-er met alleen Microsoft-kennis en geen open source kennis een slechte keuze. Hetzelfde geldt andersom. De ontbrekende kennis kan uiteraard aangevuld worden door extra opleidingen en certificeringen, maar veelal is externe ondersteuning te adviseren. Hierin is het dus belangrijk om te bedenken welke zaken er intern belegd kunnen worden en welke bij een externe partij.

Ondersteuning
‘Het is open source, dus ondersteuning is niet nodig’. Dit is één van de meest gemaakte fouten. Een commercieel bedrijf heeft commerciële ondersteuning nodig, helemaal als bedrijfskritische processen gebruik maken van open source software. Het is belangrijk om te weten dat er altijd iemand is die een probleem kan oplossen. Bij commerciële ondersteuning is kennis ook belangrijk. Niet alle certificeringen zijn hetzelfde en niet elke externe partij heeft kennis van open source producten én van bijvoorbeeld Microsoft producten. Kies dus de juiste partner die ondersteuning en begeleiding biedt, met de juiste kennis en ga vooral eventuele referenties na. 

Betrek de gebruikers
Een migratie is meer dan alleen een IT-aangelegenheid. De gebruikers zijn de personen die uiteindelijk het meeste gebruik maken van het nieuwe product. Zorg er voor dat gebruikers van het begin af aan betrokken zijn. Laat de gebruikers vanaf het begin meedenken en betrek ze in het testen van het nieuwe product. Wijs bijvoorbeeld een aantal key-users aan, die verantwoordelijk zijn voor het testen binnen hun eigen team. Dit onderdeel is cruciaal voor het uiteindelijk goedkeuren van het nieuwe product. Een nieuw product in gebruik nemen zonder dit uitvoerig te (laten) testen, is de meest gemaakte fout.

Maak gebruik van de community
Een open source product bestaat dankzij de inspanningen van de open source community. Deze community voert ontwikkelingen uit en bewaakt de kwaliteit van de software en documentatie. De gebruikers spelen hier een grote rol in, omdat deze bugs aan kunnen melden, ideeën voor nieuwe functionaliteit kunnen aanbrengen en patches kunnen aanleveren. Maak dus gebruik van deze community. Zowel de IT-afdeling als de, ingehuurde, externe partij kunnen altijd terugvallen op de community voor de nodige ondersteuning.

Maak een migratieplan
Het allerbelangrijkste van een goede migratie is het maken van een migratieplan. Dit migratieplan, dat zowel door de IT-afdeling als de externe partij gemaakt kan worden, bevat de hele migratie van begin tot eind. Zorg er voor dat dit document altijd up-to-date is en verspreid dit onder alle betrokkenen. In dit migratieplan moet duidelijk zijn van waar naar waar wordt gemigreerd, hoe deze keuze is ontstaan, hoe de migratie wordt gedaan, door wie dit wordt gedaan, welke gebruikers er testen etc. Zorg ook voor een goed fallback scenario wanneer de migratie fout gaat en er snel teruggeschakeld moet worden naar het oude oorspronkelijke product.

Over de auteur
Christiaan van Aken werkt als IT Architect bij LinProfs. Het bedrijf is gespecialiseerd in Linux en Open Source. Als specialist is hij onder andere ingehuurd door Terma A/S voor een project bij de European Space Agency (ESA Estec).