Legacy PHP naar Next.js migreren met AI: mijn aanpak voor een 10 jaar oud project
Ik heb net een migratie afgerond van een 10 jaar oud Laravel project naar Next.js. Normaal zou dit weken tot maanden kosten. Met AI deed ik het in 12 dagen. Hier is hoe.
**De uitgangssituatie:**
- Laravel 8 monolith, ~200 Blade templates, ~80 controllers
- MySQL database met 45 tabellen
- Geen tests (natuurlijk niet, het is legacy code)
- 3 jaar achterstallig onderhoud
**Mijn strategie:**
Niet alles in een keer migreren. Ik heb het opgesplitst in fases:
1. **Database eerst** (2 dagen): Supabase opgezet, MySQL dump geimporteerd via een migratescript. Claude schreef het script na het zien van mijn schema
2. **API routes** (3 dagen): Elke Laravel controller omgezet naar Next.js API routes. Claude vertaalde de PHP logica naar TypeScript. Ik reviewde elke route handmatig
3. **Frontend** (5 dagen): Blade templates naar React componenten. Dit was het meeste werk omdat de templates vol stonden met inline PHP logica
4. **Auth + middleware** (2 dagen): Laravel Auth vervangen door Supabase Auth met Row Level Security
**Waar AI het meeste hielp:**
- PHP-naar-TypeScript vertaling. Claude begrijpt beide talen goed en de conversies waren 90% correct
- Database queries omzetten van Eloquent naar Supabase client. Bijna alles werkte direct
- Blade template logica uitpakken en in React state management zetten
**Waar AI het NIET kon:**
- Business logic begrijpen. Sommige controllers hadden logica die nergens gedocumenteerd was. Daar moest ik de oude developer bellen
- Edge cases in de data. De MySQL database had inconsistenties die pas opvielen na migratie
- Performance tuning. De Supabase queries waren trager dan de geoptimaliseerde Eloquent queries. Moest handmatig indexen toevoegen
Het project draait nu 2 weken op Vercel en de klant is tevreden. Snellere laadtijden, makkelijker te onderhouden, en eindelijk een moderne stack.
Dit is een van de beste use cases voor AI die ik gezien heb. Legacy code migreren is normaal een nachtmerrie. Hoe ging Claude om met de Eloquent relationships? Dat is vaak het lastigste om te vertalen naar een andere ORM of raw queries.
De simpele hasMany/belongsTo relaties gingen goed. Het werd lastiger bij polymorphic relationships en pivot tables met extra kolommen. Daar moest ik handmatig Supabase joins schrijven. Maar Claude begreep in ieder geval wat de relatie DEED, ik hoefde alleen de implementatie aan te passen.
Hoe heb je de deployment gedaan? Grote bang switchover of geleidelijk? Bij legacy migraties is dat vaak het engste moment. Wij doen altijd een periode dual-running waar beide systemen naast elkaar draaien.
Grote bang switch, maar met een terugvalplan. De oude server stond nog 2 weken aan. We hadden 1 probleem op dag 3: een cron job die ik vergeten was te migreren. Verder liep het soepel. Dual-running is veiliger maar ook complexer om op te zetten.
12 dagen voor een complete migratie van een 10 jaar oud project is indrukwekkend. Ik zou wel benieuwd zijn hoe het over 6 maanden draait. Soms komen de echte problemen pas later: edge cases in de data, performance issues bij piekbelasting, dat soort dingen.
Die tip over "de oude developer bellen" is zo waar. AI kan code lezen maar niet de context begrijpen van waarom iemand 8 jaar geleden een rare workaround heeft gebouwd. Documentatie is goud waard, en bij legacy projecten is die er bijna nooit.