Deze overeenkomst beschrijft de praktische bescherming die we toepassen wanneer we een live website converteren of migreren naar WordPress. Het doel is een voorspelbaar, controleerbaar en veilig traject.
KernprincipeUw live website wordt niet gebruikt als bouwwerf.
VeiligheidsmodelStaging → backup → goedgekeurde cutover → verificatie → rollback-pad.
AcceptatiebasisHet project wordt geaccepteerd nadat afgesproken controles slagen, niet op basis van gokwerk.
1. Beschermingsafspraken
| Bescherming | Wat het betekent | Waarom het belangrijk is |
|---|---|---|
| Staging-first bouw | De nieuwe WordPress-versie wordt gebouwd en beoordeeld buiten uw live site. | Uw huidige website blijft beschikbaar terwijl het werk loopt. |
| Backup vóór cutover | Bestaande bestanden en database worden geback-upt vóór productiewijzigingen. | Er is een herstelpad als er iets onverwachts gebeurt. |
| Visuele pariteit | Belangrijke pagina’s worden gecontroleerd tegenover het originele ontwerp en de contentverwachtingen. | Bezoekers mogen niet verrast worden door layout-afwijkingen. |
| Beschermde cutover | Launch wordt behandeld als een gecontroleerde stap, niet als experiment. | Risico wordt beperkt op het gevoeligste moment van het project. |
| Verificatierapport | Belangrijke pagina’s, links, formulieren, redirects en stagingreferenties worden gecontroleerd. | U weet wat getest werd vóór acceptatie. |
2. Wat gebeurt vóór livegang
- De staged WordPress-versie wordt klaargemaakt voor review.
- Kritieke pagina’s en templates worden gecontroleerd op layout en inhoud.
- Bekende risico’s, redirects, formulieren, taalvarianten en integraties worden genoteerd.
- Een rollback-pad wordt bepaald vóór productiewijzigingen beginnen.
3. Wat gebeurt tijdens cutover
Cutover is een geplande technische stap. We vermijden improvisatie op productie. Als een probleem niet veilig opgelost kan worden, gebruiken we rollback in plaats van een gebroken live site achter te laten.
4. Wat gebeurt na lancering
- Belangrijke pagina’s geven succesvolle HTTP-responses.
- Belangrijke links en redirects worden gecontroleerd.
- Formulieren worden getest via het echte bezorgpad waar van toepassing.
- Staging- of development-URL’s worden gecontroleerd zodat ze niet publiek zichtbaar blijven.
- Tijdelijke import- of fixescripts worden verwijderd na gebruik.
5. Verantwoordelijkheden van de klant
Klanten leveren correcte toegangsgegevens, keuren staged werk goed vóór launch, vermijden conflicterende live wijzigingen tijdens cutover en melden post-launch problemen snel.
Kort gezegd: we scheiden bouwen van productie, bereiden rollback voor vóór launch en verifiëren het eindresultaat vóór de migratie als compleet geldt.