We begonnen met het begrijpen van elke applicatie zoals deze in het wild draaide, waar deze van afhankelijk was, wat deze bij het opstarten configureerde en hoe deze zich gedroeg onder belasting. Dat betekende het in kaart brengen van externe services (databases, caches, opslag, zoeken en gedeelde bestandssystemen), het verzamelen van omgevingsconfiguratie van EC2 en het vertalen van de bestaande Ansible-opzet naar container-vriendelijke conventies.

Elke applicatie kreeg een Dockerfile en een lichtgewicht opstartscript dat de originele Ansible-taken weerspiegelde. Binnen Kubernetes draaide PHP samen met Nginx in dezelfde pod om het bedieningsmodel waaraan teams gewend waren te behouden, terwijl ze tegelijkertijd de consistentie van containerimages over staging en productie verkregen. We hebben een standaard Helm-chart geïntroduceerd om de applicatieconfiguratie overzichtelijk en herhaalbaar te houden en om zaken vast te leggen zoals omgevingsvariabelen, resourcegrenzen en persistente mounts.

Releases zijn overgezet naar een continu model: GitHub Actions bouwt en pusht nu images; Argo CD implementeert op EKS op een gecontroleerde, controleerbare manier. Staging-omgevingen gaven ontwikkelaars een eenvoudige plek om end-to-end gedrag te valideren voordat ze wijzigingen doorvoeren. Ten slotte voltooiden DNS-updates via Route 53 de overschakeling met minimale verstoring.