FileMaker migreren naar een moderne webapp

Uw FileMaker-oplossing draait misschien al vijftien jaar trouw mee — orderbeheer, klantenadministratie, projectplanning, voorraadlijsten. Toch komen er steeds meer signalen dat de toekomstvastheid eroderet: Claris (Apple) sloot in 2024 nieuwe Server-licenties voor niet-bestaande klanten, ontwikkelaars met FileMaker-ervaring worden zeldzamer, en mobiele toegang via Web Direct loopt tegen prestatie-grenzen aan. Wij begeleiden Nederlandse MKB-organisaties bij een rustige, gefaseerde migratie naar een moderne webapplicatie — met behoud van uw bedrijfslogica, zonder big-bang-risico.

FileMaker Pro / Claris Pro DDR-export JDBC/ODBC datamigratie Schema-mapping Parallelrun Webapp op maat

Bespreek uw migratie Bekijk de redenen

Het moment dat FileMaker geen toekomstvaste keuze meer is

FileMaker (sinds 2019 verder gegaan onder de naam Claris Pro) heeft jarenlang een unieke plek ingenomen: snel iets bouwen voor één team, zonder een volledige softwareafdeling op te tuigen. Voor veel Nederlandse MKB-organisaties draait er nog steeds een FileMaker-oplossing achter de schermen — soms al sinds FileMaker Pro 7 of 11. Dat heeft prima gewerkt. De vraag is niet of FileMaker ooit goed was, maar of het nu nog de juiste fundering is voor de komende tien jaar.

In 2024 maakte Claris bekend dat nieuwe organisaties die nog niet eerder klant waren, geen Claris Server meer kunnen aanschaffen. Bestaande klanten kunnen verlengen, maar de instroom van nieuwe gebruikers is feitelijk gestopt. Tegelijk is het platform hernoemd naar Claris Pro en Claris Studio, met een sterkere koppeling aan het Apple-ecosysteem. Voor uw lopende oplossing betekent dit nog geen acuut probleem, maar wel een richting: het ontwikkelaarsbestand krimpt, derde-partij-tools verdwijnen, en de routekaart wordt smaller in plaats van breder.

Daar komt bij dat de gebruiksverwachtingen van uw medewerkers en klanten de afgelopen jaren fundamenteel zijn veranderd. Toegang via een browser op iedere device, real-time samenwerking, mobiele invoer in het veld, koppelingen met boekhouding, e-commerce en logistiek-platforms — dat soort eisen liggen vandaag bij ieder MKB-bedrijf op tafel. FileMaker WebDirect en de FileMaker Data API kunnen veel, maar lopen tegen grenzen aan zodra het aantal gelijktijdige gebruikers stijgt of de UI complexer wordt dan een set Layouts toelaat.

Wij zijn geen anti-FileMaker-club. Voor sommige situaties — een kleine afdelingstool die jaren stabiel draait — is migreren overdreven. Maar als u zichzelf herkent in twee of meer van de zes redenen hieronder, is het verstandig om de migratie nú te plannen, in plaats van wanneer het platform u ergens dwingt te springen.

Zes praktische redenen om uw FileMaker-oplossing te vervangen

Niet alle pijn ontstaat op hetzelfde moment. Sommige organisaties merken eerst de kostenstijging, andere lopen vast op het vinden van een nieuwe ontwikkelaar. Onderstaande zes patronen zien wij het vaakst terug bij gesprekken over een migratiepad.

📈

Stijgende licentiekosten per gebruiker

Claris hanteert per-user-licenties die meegroeien met uw team. Een organisatie die van vijftien naar veertig medewerkers groeit, ziet de jaarlijkse FileMaker-rekening evenredig stijgen — terwijl een eigen webapp doorgaans geen extra licentiekosten per gebruiker kent. Bij een groeitraject is dat een structureel kostenverschil dat zich elk jaar herhaalt.

🧑‍💻

Schaarste aan FileMaker-ontwikkelaars

De pool van FMP-ontwikkelaars in Nederland is klein en vergrijst. Een goede FileMaker-developer vinden voor onderhoud, uitbreiding of een script-engine-issue duurt steeds langer en wordt duurder. Een webapp gebouwd op gangbare stacks (TypeScript, PostgreSQL, REST/GraphQL) heeft een veel breder ontwikkelaarsbestand — ook voor onderhoud over vijf of tien jaar.

📱

Mobiele beleving haalt het niveau niet

FileMaker Go op iPad werkt voor gestructureerde invoer, maar Web Direct op smartphones voelt traag en verouderd voor wie gewend is aan moderne progressive web apps. Voor monteurs in het veld, salesteams onderweg of klanten die vanuit de browser bestellen, is de UX-kloof inmiddels groot genoeg om commercieel relevant te zijn.

🔌

Integratie met externe systemen wordt complex

De FileMaker Data API is functioneel, maar het bouwen van robuuste, twee-richting-koppelingen met bijvoorbeeld Exact Online, Magento, Shopify, Microsoft Dynamics of een marketplace-API kost veel werk in script-stappen en cURL-opties. Een webapp met een eigen backend praat veel directer met deze externe API's, met betere error-handling en logging.

⚡

Performance bij grotere datasets

FileMaker werkt prima tot enkele honderdduizenden records, maar bij miljoenen records, complexe relaties en zware Calculation-velden zien we de zoek- en sorteersnelheid achteruit gaan. Een PostgreSQL- of MySQL-backend met de juiste indexen kan datasets verwerken die in FileMaker het systeem ongebruikelijk traag maken.

☁️

On-premises deploy past niet meer

Veel FileMaker-omgevingen draaien nog op een eigen server of een gehoste FileMaker Server. Voor remote-werken, ISO 27001-eisen of klanten die SaaS-toegang verwachten, is een cloud-native webapp (containers, automatische backups, EU-hosting) een logischere fundering. Migreren is dan ook een infrastructuur-modernisering, niet alleen een software-vervanging.

Hoe wij een FileMaker-oplossing veilig naar een webapp migreren

Een FileMaker-migratie is geen export-import. Uw oplossing bevat jaren aan opgebouwde bedrijfslogica — verstopt in scripts, calculations, layouts en custom functions. Wij bouwen geen lift-and-shift-kopie, maar reconstrueren uw oplossing in een moderne webapp, met behoud van wat werkt en herziening van wat in FileMaker te omslachtig was geworden.

De eerste stap is altijd een schema-extractie. Met de Database Design Report (DDR) van FileMaker exporteren we uw volledige tabelstructuur, veldtypen, relaties, layouts, scripts, value lists en accounts naar XML. Die XML is voor ons leesbare documentatie van uw oplossing — en de basis voor het mappen naar een relationeel database-schema (PostgreSQL of MySQL). Calculation-velden vertalen we naar database-functies of backend-logica; container fields naar object-storage met file-references in de database.

Voor de data-export gebruiken we afhankelijk van het volume drie technieken: ExportFieldContents voor binaire bestanden in container fields, JDBC/ODBC voor bulk-exports naar staging-tabellen, en de FileMaker Data API voor incrementele synchronisatie tijdens de parallelrun. Op die manier kunnen we per tabel valideren of de data in de nieuwe webapp identiek is aan de bron, voordat de oude oplossing wordt uitgezet.

De business-logica uit uw FM-scripts is meestal het meest tijdrovende onderdeel. Wij analyseren elk script — dat zijn er bij volwassen oplossingen vaak honderden — en groeperen ze naar functioneel doel: validatieregels, workflow-triggers, rapportage, bulkoperaties. De relevante regels reconstrueren we als services in de backend van de nieuwe webapp, met unit-tests waar het kritisch is. Achterhaalde scripts (bijvoorbeeld voor uitgefaseerde processen) gaan niet mee — dat is een natuurlijk moment voor opschoning.

Tot slot draaien we minimaal enkele weken parallel: de FileMaker-oplossing en de nieuwe webapp staan beide live, met dagelijkse data-synchronisatie. Uw team werkt eerst dubbel of test in de nieuwe omgeving naast de oude, vergelijkt rapportages en signaleert afwijkingen. Pas wanneer alle stakeholders vertrouwen hebben in de nieuwe oplossing, wordt FileMaker uitgezet. Geen big-bang-go-live, geen afhankelijkheid van één migratie-weekend dat per se moet slagen.

Access database vervangen Legacy software vervangen Custom software laten maken Platform migratie

De vier fasen van een FileMaker-migratie

Onze aanpak is iteratief en transparant. Elke fase levert een toetsbare deliverable op, zodat u op ieder moment kunt bijsturen of de scope kunt herzien — zonder vast te zitten aan een vooraf vastgepind eindplaatje.

DDR-analyse en scope

We exporteren de Database Design Report uit uw FileMaker-oplossing en inventariseren alle tabellen, relaties, layouts, scripts en custom functions. Op basis daarvan stellen we samen een migratiescope vast — wat gaat één-op-één mee, wat wordt vereenvoudigd, en wat valt af.

Schema-mapping en POC

We mappen uw FileMaker-schema naar een relationele database (meestal PostgreSQL) en bouwen een proof of concept van de meest kritische module. U ziet de nieuwe UX, de performance op echte data, en kunt valideren of de aanpak werkt voordat we de volledige migratie starten.

Bouw en parallelrun

We bouwen de volledige webapp module voor module. Tijdens de bouwfase loopt al een data-pipeline van FileMaker naar de nieuwe omgeving, zodat we bij elke iteratie kunnen testen op productiedata. Uw team werkt nog op FileMaker; de webapp groeit naast de oude oplossing.

Cutover en decommissioning

Wanneer alle modules zijn opgeleverd en getest, knippen we over. Uw team werkt voortaan in de webapp; FileMaker blijft nog enkele weken read-only beschikbaar als referentie. Daarna wordt de Claris Server uitgefaseerd en zijn de licentiekosten weg.

Technologieën die wij inzetten bij FileMaker-migraties

De technologiekeuze hangt af van uw situatie: het aantal gelijktijdige gebruikers, de hoeveelheid data, de eisen aan mobiele werking en de bestaande integraties. We werken met bewezen open-source-stacks die over tien jaar nog steeds onderhoudbaar zijn, en houden de complexiteit zo laag mogelijk — wat eenvoudig kan, bouwen we eenvoudig.

Voor de data-extractie uit FileMaker gebruiken we de officiële DDR-export (XML), JDBC- en ODBC-connectoren, ExportFieldContents voor container-bestanden, en de FileMaker Data API voor incrementele sync tijdens de parallelrun. Aan de webapp-kant kiezen we voor TypeScript-frameworks (React, Astro, Next.js of Remix) met een Node.js- of Python-backend, gekoppeld aan PostgreSQL of MySQL. Hosting bij voorkeur in EU-datacenters voor AVG-conformiteit.

FileMaker DDR (XML) JDBC / ODBC FileMaker Data API PostgreSQL MySQL TypeScript React Node.js Python REST / GraphQL Docker PWA

Concrete use cases die wij vanuit FileMaker hebben gemoderniseerd

FileMaker zit in heel verschillende hoeken van een bedrijf. Onderstaande drie patronen zien wij het meest terug bij MKB-organisaties die met een migratie aan de slag willen.

Orderbeheer en offerte-tooling

Een groothandel die al jaren orders, offertes en pakbonnen in FileMaker beheert, loopt vast op koppelingen met de webshop en de boekhouding. De bestaande workflow — van inkomende order via picking tot factuur — reconstrueren we als webapp met REST-koppeling naar het ERP. Buitendienstmedewerkers werken voortaan via een PWA op telefoon en tablet, en de magazijnchef ziet realtime voorraadstanden.

Klantenadministratie en CRM

Een dienstverlener heeft een FileMaker-CRM met klanten, contactmomenten, contracten en facturen — opgebouwd over twaalf jaar. De migratie levert een webapp met dezelfde datamodellen, maar met moderne search, automatische e-mail-templating, koppeling naar de telefooncentrale en een klantportaal waar klanten hun eigen gegevens en facturen kunnen inzien.

Projectplanning en urenregistratie

Een ingenieursbureau gebruikt FileMaker voor projecten, taken en uren. De nieuwe webapp houdt dezelfde structuur aan — projecten met fasen, taken met geschatte en geboekte uren — maar voegt een Gantt-view toe, automatische facturatie op basis van contracttypen en een mobiele app voor uren onderweg invoeren. De rapportage richting opdrachtgevers gebeurt voortaan in de webapp zelf.

Voorraadbeheer en logistiek

Een productiebedrijf draait voorraad, inkoop en kwaliteitscontrole in FileMaker. We migreren naar een webapp met barcode-scanning op de werkvloer (PWA op Android-scanners), realtime dashboards voor de productieleider en API-koppelingen met leveranciersportalen. De FileMaker-rapportages reconstrueren we als BI-views in de nieuwe omgeving.

Waarom Appfront voor uw FileMaker-migratie

Respect voor wat werkt

Uw FileMaker-oplossing bestaat niet voor niets. Wij beginnen met begrijpen waarom het platform destijds is gekozen, en welke logica nu cruciaal is voor uw bedrijfsvoering. Geen migratie waarbij de helft van de functionaliteit verloren gaat omdat het 'modern' moest.

Parallelrun in plaats van big-bang

Wij geloven niet in migraties die afhangen van één weekend. Onze aanpak is altijd parallel: oude en nieuwe oplossing draaien tegelijk, met dagelijkse data-sync. Uw team kan rustig wennen, vergelijken en bijsturen voordat FileMaker uitgaat.

Onderhoudbare stack voor de lange termijn

Wij bouwen op gangbare open-source-frameworks waar volgende jaar ook nog ontwikkelaars voor te vinden zijn. Geen nichetech, geen vendor-lock. U kunt over vijf jaar zonder paniek wisselen van leverancier — wij zijn gewoon zo zelfverzekerd dat we er over vijf jaar nog zijn.

Plan een vrijblijvend gesprek Proof of concept laten maken Webapp laten maken

Veelgestelde vragen over FileMaker-migratie

Moet ik nu echt al weg van FileMaker?

Niet per se vandaag. Bestaande Claris-klanten kunnen hun licenties verlengen en het platform draait technisch nog jaren door. De vraag is meer: hoe lang nog wilt u afhankelijk zijn van een platform waar Claris nieuwe servers niet meer aan nieuwe klanten verkoopt, en waar de ontwikkelaarspool krimpt? Wij raden aan om in elk geval het migratiepad in kaart te brengen, zelfs als u nog twee tot drie jaar wilt blijven.

Verlies ik tijdens de migratie data of historie?

Nee. Onze migratie-aanpak is altijd reversibel tot het cutover-moment. Tijdens de parallelrun staat FileMaker gewoon nog operationeel, en na cutover blijft de oude omgeving nog enkele weken read-only beschikbaar. Datavalidatie gebeurt per tabel — we vergelijken aantallen records, checksums op kritische velden en steekproeven op edge cases. Pas wanneer alle data identiek is in de nieuwe omgeving, gaat de oude uit.

Hoe lang duurt een FileMaker-migratie ongeveer?

Dat hangt af van de omvang van uw oplossing. Een kleine afdelingstool (twintig tabellen, vijftig scripts, één team) kan in zes tot twaalf weken. Een volwassen bedrijfsoplossing (honderd tabellen, vijfhonderd scripts, meerdere teams en integraties) is doorgaans een traject van zes tot twaalf maanden inclusief parallelrun. We werken in iteraties van twee weken, zodat u steeds voortgang ziet.

Wat gebeurt er met onze huidige FileMaker-scripts en custom functions?

Die analyseren we via de DDR-export en groeperen we naar functioneel doel. De relevante logica reconstrueren we in de backend van de nieuwe webapp — meestal in TypeScript of Python, met unit-tests voor kritische regels. Achterhaalde scripts (van uitgefaseerde processen, debug-routines, eenmalige imports) gaan niet mee. Dat scheelt vaak twintig tot veertig procent van het scriptbestand.

Werkt de nieuwe webapp net zo snel als FileMaker op het LAN?

In de praktijk vrijwel altijd sneller bij grotere datasets. FileMaker is razendsnel op kleine sets via een snel LAN, maar verliest terrein bij miljoenen records of complexe Calculation-velden. Een goed-geïndexeerde PostgreSQL achter een moderne webapp blijft consistent presteren tot ver in de tientallen miljoenen records. Voor mobiele en remote-werkende gebruikers is een webapp doorgaans aanmerkelijk sneller dan FileMaker WebDirect.

Kunnen we modules per stuk migreren in plaats van alles tegelijk?

Ja, en dat is vaak verstandig. We kunnen bijvoorbeeld eerst klantenadministratie en CRM migreren, dan orderverwerking, dan rapportage. Tijdens de overgang draaien beide systemen via een data-sync, zodat klantgegevens consistent blijven tussen de webapp en het FileMaker-deel dat nog leeft. Dit verlaagt het risico en verspreidt de investering.

Wat als we externe FileMaker-plugins gebruiken?

Plugins zoals BaseElements, MBS, 360Works of Productive Computing inventariseren we in de DDR-fase. Voor elke plugin bepalen we of de functionaliteit nodig is in de webapp — meestal is er een open-source- of cloud-equivalent (e-mail-versturen, PDF-genereren, OCR, FTP/SFTP). De plugin-functionaliteit wordt herbouwd in de backend zodat u na migratie geen plugin-licentiekosten meer heeft.

Wat kost een FileMaker-migratie ongeveer?

De investering hangt af van de omvang van uw oplossing en de gewenste verbeteringen aan UX en functionaliteit. We starten altijd met een DDR-analyse en een proof of concept op één module — dat geeft u een realistisch beeld van scope, doorlooptijd en kosten voordat u zich aan een volledig traject committeert. Geen vooraf-vastgepinde projectprijs, wel een transparante uurschatting per fase.

Uw FileMaker-oplossing klaarmaken voor de volgende tien jaar?

Plan een vrijblijvend gesprek. We kijken samen naar uw huidige FileMaker-omgeving, bespreken een realistisch migratiepad en starten desgewenst met een DDR-analyse om scope en doorlooptijd helder te krijgen.

Plan een gesprek