Definitie: Go-live, in het Nederlands ook livegang, is het moment waarop nieuwe software, een website of een systeem in gebruik wordt genomen door echte gebruikers met echte gegevens. Het markeert de overgang van ontwikkelen en testen naar de dagelijkse praktijk.
In het kort
- De go live betekenis is letterlijk “live gaan”: de applicatie draait vanaf dat moment in de productieomgeving en testgegevens maken plaats voor echte gegevens.
- Een livegang kan in één keer (big bang) of stap voor stap gebeuren, bijvoorbeeld eerst voor één gebruikersgroep.
- Vlak voor de livegang volgt een go/no-go-besluit op basis van een checklist: is alles getest, zijn gegevens overgezet en weet iedereen wat er verandert?
- Na de livegang volgt een periode van extra nazorg, vaak hypercare genoemd, waarin problemen snel worden opgelost.
Wat is de go live betekenis?
Go-live komt uit het Engels en betekent live gaan. In softwareprojecten is het de mijlpaal waarop een nieuwe applicatie of een nieuwe versie beschikbaar komt voor de mensen die ermee gaan werken. Volgens Kern-IT is het de overgang van ontwikkeling naar echte operatie, waarbij productiegegevens de testgegevens vervangen.
In het Nederlands spreken we van livegang, livezetting of in productie nemen. Het woord wordt ook buiten software gebruikt, bijvoorbeeld voor een nieuwe website, webshop of campagne. Op sociale media betekent “go live” iets anders: een livestream starten. In dit artikel gaat het om de livegang van software.
Een livegang is meer dan een technische handeling. Op dat moment gaan mensen anders werken. Een planner gebruikt een nieuw scherm, een klant logt voor het eerst in op een portaal, een oude spreadsheet verdwijnt. Daarom draait een goede livegang net zo goed om gebruikers, communicatie en ondersteuning als om servers en code.
Waarom is de livegang zo’n belangrijk moment?
Tot de livegang kun je alles nog aanpassen zonder dat iemand er last van heeft. Daarna werkt de organisatie op het systeem. Een fout in de testomgeving is een melding; een fout na de livegang kan betekenen dat orders blijven liggen, klanten niet kunnen inloggen of facturen verkeerd worden verstuurd.
Kern-IT noemt de eerste 48 uur na een livegang kritiek. In die periode komen problemen boven die in tests niet zichtbaar waren, omdat echte gebruikers het systeem anders gebruiken dan testers en echte gegevens rommeliger zijn dan testgegevens.
Welke strategieën voor een livegang zijn er?
| Strategie | Hoe het werkt | Geschikt voor |
|---|---|---|
| Big bang | Iedereen stapt op hetzelfde moment over op het nieuwe systeem | Kleine organisaties, of systemen die niet naast elkaar kunnen draaien |
| Gefaseerd | Eerst één afdeling, vestiging of gebruikersgroep, daarna de rest | Grotere organisaties, systemen met veel gebruikers |
| Parallel | Oud en nieuw systeem draaien een tijd naast elkaar | Bedrijfskritische processen waar zekerheid belangrijker is dan tijd |
| Blue-green | Twee identieke omgevingen; het verkeer wordt in één keer omgezet naar de nieuwe | Webapplicaties waar snel terugschakelen mogelijk moet zijn |
| Canary | Eerst een klein deel van de gebruikers krijgt de nieuwe versie | Applicaties met veel gebruikers, om risico te spreiden |
Kern-IT beschrijft de gefaseerde aanpak, blue-green en canary als gangbare strategieën. Welke strategie past, hangt af van het aantal gebruikers, de afhankelijkheid van het systeem en de vraag of oude en nieuwe werkwijze naast elkaar kunnen bestaan.
Wat hoort er op een livegang checklist?
Een checklist voorkomt dat iets wordt vergeten en maakt het go/no-go-besluit minder emotioneel. Op basis van de checklists van Microsoft, Moxo en ProjectManagement.com zijn dit de belangrijkste onderdelen:
Techniek
- De productieomgeving is ingericht, beveiligd en getest.
- Back-ups en monitoring staan aan.
- Koppelingen met andere systemen zijn getest, ook voor het geval een extern systeem niet bereikbaar is.
- Er is een terugvalplan: hoe zet je de oude situatie terug als het misgaat?
Gegevens
- De datamigratie is meerdere keren getest, met controle op ontbrekende en dubbele records.
- De migratie past binnen het tijdvenster van de livegang.
- De eigenaar van de gegevens heeft het resultaat goedgekeurd.
Testen
- De acceptatietest is afgerond door mensen uit de organisatie, niet alleen door de ontwikkelaar.
- Zowel de normale route als uitzonderingen zijn getest, met echte of gemigreerde gegevens.
- Gebruikersrollen en rechten zijn gecontroleerd.
Mensen
- Gebruikers weten wat er voor hen verandert en wanneer.
- Training of uitleg is gegeven, afgestemd op de rol.
- Er is een duidelijk aanspreekpunt voor vragen en problemen.
Planning
- Er is een draaiboek met tijdstippen, taken en verantwoordelijken.
- Er is een contactlijst van iedereen die op de dag van de livegang nodig kan zijn.
- Het go/no-go-moment is gepland.
Wat is een go/no-go-besluit?
Kort voor de livegang beslissen de betrokkenen of het systeem live kan. Dat is het go/no-go-besluit. De checklist is daarbij het uitgangspunt: zijn alle punten afgevinkt, dan is het systeem klaar. Volgens ProjectManagement.com zorgt dat gesprek ook voor gedeelde verantwoordelijkheid tussen opdrachtgever, gebruikers, IT en leverancier.
Hetzelfde artikel adviseert om het go/no-go-gesprek kort voor de livegang te houden, maar niet op dezelfde dag, en om een systeem niet op vrijdag live te zetten. In het weekend zijn er vaak te weinig mensen beschikbaar om problemen op te lossen.
Een no-go is geen mislukking. Het betekent dat een risico te groot is om nu te nemen. Beter een week later live dan een week lang problemen.
Hoe ziet een livegang er in de tijd uit?
Moxo verdeelt de voorbereiding van een grotere implementatie in fasen:
| Moment | Activiteit volgens Moxo |
|---|---|
| 8 tot 12 weken vooraf | Planning, scope, verantwoordelijkheden en terugvalplan |
| 4 tot 6 weken vooraf | Datamigratie voorbereiden en proefmigraties uitvoeren |
| 2 tot 4 weken vooraf | Gebruikers voorbereiden met training en communicatie |
| 1 week vooraf | Laatste controles en go/no-go-besluit |
| De dag zelf | Draaiboek uitvoeren, controleren en communiceren |
| Week 1 en 2 erna | Nazorg met dagelijkse controles en snelle opvolging van meldingen |
Voor een kleine webapplicatie met een handvol gebruikers kan dit veel compacter. Het principe blijft hetzelfde: eerst afbakenen, dan gegevens, dan mensen, dan de overstap en daarna nazorg.
Livegang van een kleine webapplicatie
Niet elke livegang is een groot project met maanden voorbereiding. Bij een kleine interne tool of een eerste versie van een klantportaal ziet een livegang er vaak zo uit:
- Een korte acceptatieronde waarin twee of drie toekomstige gebruikers de belangrijkste taken uitvoeren op de productieomgeving, met echte gegevens.
- Gegevens overzetten uit de spreadsheet of het oude systeem, en steekproefsgewijs controleren.
- Accounts aanmaken en rollen controleren: ziet iedereen alleen wat bij zijn rol hoort?
- Een korte uitleg aan gebruikers, met een aanspreekpunt voor vragen.
- Een vast moment kiezen, bij voorkeur aan het begin van de week.
- De eerste dagen actief meekijken naar foutmeldingen en vragen.
De oude werkwijze laat je liefst niet meteen verdwijnen. Een week waarin de oude spreadsheet nog als naslag beschikbaar is, geeft gebruikers houvast zonder dat er twee systemen tegelijk worden bijgehouden.
Wat gebeurt er na de livegang?
Na de livegang begint de nazorgperiode, vaak hypercare genoemd. Microsoft noemt hypercare direct na de livegang als onderdeel van de operationele voorbereiding, samen met monitoring, een overdracht naar het supportteam en een helpdeskproces.
In die periode:
- staat het team extra paraat om meldingen snel op te pakken;
- worden foutmeldingen, laadtijden en koppelingen dagelijks gecontroleerd;
- wordt feedback van gebruikers verzameld en beoordeeld;
- worden kleine verbeteringen snel doorgevoerd;
- wordt aan het eind afgesproken hoe het reguliere beheer verloopt.
Een livegang is dus geen eindpunt. Het is het moment waarop je voor het eerst ziet hoe de software in de praktijk wordt gebruikt.
Veelgemaakte fouten bij een livegang
- Alleen technisch testen. Volgens Whatfix bewijst een acceptatietest dat het systeem werkt, niet dat gebruikers hun taken zelfstandig kunnen uitvoeren.
- Geen getest terugvalplan. Moxo stelt het scherp: een ongetest terugvalplan is een document, geen vangnet.
- Datamigratie onderschatten. Gegevensproblemen komen vaak pas na de livegang boven.
- Gebruikers te laat informeren. Wie op maandag ineens een nieuw scherm ziet, gaat zoeken naar de oude werkwijze.
- Live op vrijdagmiddag. Problemen in het weekend blijven liggen of kosten onverwacht extra inzet.
- Geen eigenaar na de livegang. Zonder aanspreekpunt stapelen vragen zich op.
Wat betekent dit voor jouw project?
Ik wil vooraf duidelijk hebben wat we met een eerste versie bedoelen. Dat geldt ook voor de livegang: welke gebruikers gaan als eerste werken met het systeem, en welke taak moeten zij op dag één kunnen afronden? Een kleine, duidelijke eerste groep geeft sneller inzicht dan iedereen tegelijk.
Bij Webinooo, mijn eigen webinarproject, zijn registratie en streaming eerst in de praktijk getest. De bouwles daaruit is breder bruikbaar: ontwerp vanuit het moment van de gebruiker. Wat verwacht iemand direct na de overstap, hoe weet hij wat er gaat gebeuren en waar kan hij terecht met een vraag?
Vraag? Staat er een nieuw systeem of een vervanging van een oude tool op de planning? Stuur me voor wie het is, wat er nu gebeurt en wat de eerste versie moet oplossen. Dan bepalen we samen de logische eerste stap. Lees ook hoe het traject verloopt bij een webapplicatie ontwikkelen.
Veelgestelde vragen over go-live
Wat is de betekenis van go-live?
Go-live betekent dat nieuwe software of een nieuwe versie in gebruik wordt genomen door echte gebruikers met echte gegevens. In het Nederlands heet dat ook livegang of in productie nemen.
Wat staat er op een livegang checklist?
Een livegang checklist bevat onder meer een geteste productieomgeving, back-ups, een getest terugvalplan, een gecontroleerde datamigratie, een afgeronde acceptatietest, geïnformeerde gebruikers, een draaiboek en een gepland go/no-go-besluit.
Wat is hypercare na een go-live?
Hypercare is de periode direct na een livegang waarin het team extra paraat staat. Meldingen worden snel opgepakt, het systeem wordt dagelijks gecontroleerd en feedback van gebruikers wordt verwerkt, voordat het reguliere beheer begint.
Verwante termen
Datamigratie · Doorontwikkeling en onderhoud · SLA · Proof of concept · Discovery-fase · Webapplicatie
← Terug naar de kennisbank