Wat een Flutter-migratie werkelijk is
Weeg je Flutter nog af tegen React Native, lees dan eerst Flutter tegenover React Native in 2026 — deze pagina gaat ervan uit dat je al hebt gekozen en beantwoordt de uitvoeringsvraag: hoe, hoe lang, hoeveel, en hoe riskant.
Een migratie van React Native naar Flutter is een herbouw, geen overzetting. Flutter en React Native delen geen buildartefacten, geen componentbibliotheek en geen statelaag — elk scherm, elke navigatiestroom en elke native koppeling wordt vanaf nul in Dart opnieuw gebouwd. Wat de overstap overleeft is alles wat geen code is: je bedrijfsregels, je API-contracten, je datamodellen, en de ontwerpbesluiten die je team al nam. Die worden de specificatie waartegen de nieuwe app wordt gebouwd, en dat is waarom een migratie sneller en minder riskant is dan met een leeg vel beginnen — maar het blijft, eerlijk gezegd, een volledige herbouw van de client.
Wie zou moeten migreren — en wie niet
Flutter is meestal de juiste keuze voor een team dat React Native of native al in productie draait — maar niet altijd, en we zeggen dat liever vooraf dan je een herbouw te verkopen die je niet nodig hebt.
Tekenen dat het tijd is om te migreren
- De upgradetredmolen van React Native (nieuwe architectuur, brekende releases, wisselende afhankelijkheden) kost elke cyclus echte engineeringtijd
- Je loopt tegen een prestatieplafond aan — haperingen op complexe schermen, traag renderende lijsten, stotterende animaties — dat de brugarchitectuur niet kan oplossen
- Native modules zijn een onderhoudslast geworden: geforkte pakketten, op versie vastgezette afhankelijkheden, code die de oorspronkelijke auteur achterliet
- Werven is moeilijk of wisselvallig, en je wilt één team op één codebase in plaats van RN- en native specialisten
- Je bouwt nieuw werk al in Flutter en wilt dat de rest van de app daarbij aansluit
Wanneer migreren NIET de juiste keuze is
- Je app is stabiel, presteert goed, en houdt de roadmap niet tegen
- Je team is tevreden en productief, en heeft geen zin in een herbouw van maanden
- Je hebt zwaar geïnvesteerd in eigen native modules die prima werken en waarvoor geen Flutter-equivalent de moeite waard is
- Het argument om te migreren is "Flutter ziet er mooi uit" en geen echt kosten-, prestatie- of onderhoudsprobleem
De eerlijke lezing: past geen van de bovenstaande tekenen bij je app, migreer dan niet. Een stabiele app met een tevreden team is de beste app om met rust te laten. Vertel ons waar je werkelijk vastzit en we zeggen ronduit of een migratie de moeite waard is — inclusief "nog niet."
De stapsgewijze aanpak: add-to-app
De reden om met ons te migreren in plaats van een herbouw vanaf nul te bestellen is het opleveringsmodel, niet de keuze van het framework. We bedden Flutter als module in je bestaande React Native- of native app in — een add-to-app-koppeling — en verplaatsen schermen één voor één achter een gedeelde router. Niets hieraan vraagt om een big-bang omschakeling, en niets hieraan haalt je app offline.
De add-to-app-stroom
Bestaande schil blijft
Je huidige RN- of native app blijft ongewijzigd in productie draaien als gastschil
Flutter-module ingebed
Een Flutter-engine wordt via add-to-app aan de schil toegevoegd en deelt navigatie en native diensten
Schermen migreren één voor één
Elk scherm komt in Flutter achter de router uit, afzonderlijk getest en uitgebracht
RN-schermen verdwijnen
Zodra een Flutter-scherm zich in productie bewijst, wordt het RN-equivalent verwijderd, niet gearchiveerd
Volledige omschakeling
Zodra elk scherm is verhuisd, wordt de gastschil zelf verwijderd en is de app 100% Flutter
Dit gaat niet zonder wrijving. Zolang de migratie loopt draai je twee toolchains en twee statelagen naast elkaar — en, tot het designsysteem volledig is overgezet, twee visuele talen in verschillende hoeken van dezelfde app. Dat is tijdelijk méér complexiteit, geen minder. We bakenen de migratiekaart vooraf af juist om dat venster zo kort mogelijk te houden, maar we doen niet alsof het verdwijnt.
Wat meegaat tegenover wat wordt herbouwd
Niet alles gaat weg. Dit is wat de overstap naar Flutter werkelijk overleeft, en wat vanaf nul wordt herbouwd.
| Laag | Gaat mee | Herbouwd in Flutter |
|---|---|---|
| Bedrijfslogica en regels | Ja | — |
| API-contracten | Ja | — |
| Datamodellen | Ja | — |
| Designtokens en huisstijl | Ja | — |
| Testgevallen (als specificatie) | Ja | — |
| Interfaceschermen | — | Herbouwd |
| Navigatie | — | Herbouwd |
| Statebeheer | — | Herbouwd |
| Native koppelingen | — | Herbouwd |
| CI/CD-pijplijn | — | Herbouwd |
Hoe we een migratie uitvoeren
1. Audit
We nemen je codebase door — schermen, navigatie, statebeheer, native modules, API-oppervlak en testdekking — en markeren wat eenvoudig te migreren is tegenover wat werkelijk lastig wordt. Elke landmijn — een geforkte native module, een ongedocumenteerde toestandsmachine, een backendcontract dat niemand opschreef — vinden we hier, en niet drie sprints in de herbouw.
2. Migratiekaart
De audit wordt een migratieplan per scherm: volgorde, afhankelijkheden tussen schermen, welke native modules een Flutter-equivalent nodig hebben, en een realistische volgorde die de app bij elke stap uitleverbaar houdt. Dit document is waartegen de rest van het project wordt afgebakend.
3. Stapsgewijze oplevering
We bedden Flutter in je bestaande schil in en beginnen schermen op prioriteit uit te brengen — meestal eerst iets met weinig risico om de pijplijn te bewijzen, daarna de schermen die er werkelijk toe doen. Je app blijft ondertussen gewoon uitkomen; de migratie loopt naast je normale roadmap, niet in plaats daarvan.
4. Omschakeling
Zodra elk scherm is verhuisd en de oude code is verwijderd, halen we de gastschil weg en brengen we een build uit die alleen Flutter is. Vanaf dat punt wordt de app onderhouden als elke andere Flutter-codebase — één team, één toolchain.
Houd je het werk liever in eigen huis? Onze engineers van teamuitbreiding kunnen bij je team aansluiten en de migratie onder jouw eigenaarschap uitvoeren in plaats van het onze.
Verklein het risico voordat je je verbindt
Je hoeft je niet aan een volledige migratie te verbinden om te ontdekken wat er bij komt kijken. Onze dienst Audit van AI-code voert de auditfase hierboven uit als losstaande opdracht met vaste scope: een volledige beoordeling van je bestaande codebase en een geschreven rapport dat je migratiekaart wordt — landmijnen, risico rond native modules, en een realistische volgorde — of je daarna met ons verdergaat of niet.
Begin hier als je twijfelt
Een audit is de manier met de laagste drempel om te ontdekken of een migratie zinnig is voor je app, wat hij werkelijk gaat kosten, en waar het echte risico zit — voordat iemand een regel Dart schrijft.
Planning en kosten
Een Flutter-migratie schaalt als een herbouw, want dat is het — de codebase waarmee je eindigt is een volledige Flutter-app, gebouwd op dezelfde scope als wanneer je vanaf nul was begonnen. Wat de stapsgewijze aanpak verandert is het risico, niet de omvang: oplevering over schermen spreiden rekt de kalender op vergeleken met een big-bang herbouw, maar het betekent dat je app nooit uitvalt, en dat je bij elke schermgrens kunt stoppen, pauzeren of herprioriteren.
We geven geen planning of prijs voor een migratie zonder de app te hebben gezien — de bandbreedte is anders te breed om nuttig te zijn. Voor een gevoel van schaal, zie hoe we inschatten hoe lang een Flutter-app duurt om te bouwen en wat de kosten van Flutter-ontwikkeling werkelijk bepaalt; een migratie van een app met vergelijkbare omvang ligt dicht bij die cijfers, plus de fase van audit en migratiekaart vooraf.
Veelgestelde vragen
Alles wat je moet weten over migreren van React Native of native naar Flutter