Een Access-applicatie die jarenlang prima werkte loopt op een gegeven moment vast: niemand durft er nog aan, slechts één collega kent de macros, mobiel werkt het niet, en de AVG-positie is zwak. Wij migreren uw .mdb of .accdb naar een schaalbare web-app met multi-user toegang, audit-trail en een fatsoenlijke back-end.
Microsoft Access is decennialang het pragmatische antwoord geweest voor MKB-administraties, accountancy-kantoren, lokale overheid, kleine zorgpraktijken, lab-omgevingen en productie-tracking. Iemand met domeinkennis bouwde zonder ontwikkelaar een werkende applicatie — tabellen, formulieren, queries, rapporten, wat macros — alles in één bestand. In veel organisaties draait die Access-applicatie nog steeds, omdat hij «gewoon werkt».
Het probleem is dat «gewoon werkt» bedrieglijk is. Een .mdb of .accdb staat op een netwerkschijf, soms via een fileshare uit Windows Server 2008-tijd. Met één gebruiker prima; met twee een record-lock-issue; met vijf een corrupt bestand dat 's avonds geback-upt en 's ochtends hersteld moet worden. Geen mobiele app, geen audit-trail, geen rolbeheer voorbij wachtwoord-op-bestand, en logica in VBA-macros die exact één persoon nog kan ontcijferen.
Een Access-database vervangen is dus zelden een technisch luxe-project. Het is meestal een combinatie van risico-management (AVG, audit, single point of knowledge), schaalbaarheid (meer gebruikers, mobiel toegankelijk) en doorontwikkeling (uw werkproces is verder évoluéerd dan wat Access aankan). Onze aanpak past binnen onze bredere praktijk in web-ontwikkeling, en hangt nauw samen met de bredere context van platform-migratie — een Access-overstap is in de kern een platform-migratie met Access-specifieke valkuilen.
Niet elke Access-database vraagt om dezelfde aanpak. Soms is de bestaande logica zo bedrijfsspecifiek dat maatwerk de enige juiste route is. Soms is het werkproces inmiddels generiek genoeg dat een low-code platform volstaat. Vaak is het een hybride: de kern op maat, de randen low-code.
Voor relatief generieke administratie-applicaties — ledenregister, klein klantbestand, voorraad-tracking, eenvoudige formulieren-flow — bouwen we uw Access om naar Microsoft PowerApps, AppSheet of een vergelijkbare low-code-omgeving. De data verhuist naar Dataverse, SQL Server of Google Cloud SQL; de Access-formulieren worden herbouwd in de low-code-editor; rapportages gaan naar Power BI of Looker Studio. Bewust gekozen wanneer uw organisatie de oplossing zelf moet kunnen aanpassen zonder ontwikkelaar.
Voor Access-databases waarin uw bedrijfslogica leeft — specifieke berekeningen, eigen workflow, koppelingen met andere systemen — bouwen we een maatwerk web-applicatie. Data naar Postgres, MySQL of SQL Server; forms herbouwd in React, Vue of Astro als single page application; queries beschikbaar als REST- of GraphQL-API; macros vertaald naar duidelijke backend-logica. Inclusief multi-user, audit-trail en rolgebaseerde toegang.
Voor situaties waarin meerdere Access-bestanden naast elkaar leven — vaak gegroeid over jaren met overlap in data en logica — consolideren we eerst de data-laag (zie ook onze pagina over data-engineering-platformen) en bouwen daar bovenop een digitaal platform dat de Access-functionaliteit overneemt en uitbreidt. Geschikt voor organisaties die de migratie willen aangrijpen om hun rapportage- en BI-positie meteen op orde te brengen.
Geen .accdb meer op een netwerkschijf, geen VBA-macros die alleen Jan begrijpt, en geen pop-up «dit bestand wordt door iemand anders gebruikt». Wel een omgeving die u zelf kunt beheren of laten beheren, met de data en logica volledig in eigen hand.
Vijf patronen waarin organisaties bij ons aankloppen om hun Access-omgeving te vervangen. Herkent u er één, dan loont een gesprek meestal de moeite — ook als we uiteindelijk concluderen dat een lichte upgrade volstaat in plaats van een volledige vervanging.
De Access-applicatie zou multi-user moeten zijn, maar in de praktijk blokkeert de tweede gebruiker. Records raken gelocked, het bestand corrumpeert af en toe, en het ICT-team herstelt 's ochtends backups voordat de dag kan beginnen. Met enige groei van het team houdt dit niet stand.
Uw medewerkers in de buitendienst, op locatie of in een productiehal hebben geen toegang tot de Access-omgeving. Ze noteren alles op papier of in Excel en typen 's avonds over. Een web-omgeving lost dat in één keer op: tablet, telefoon, laptop — allemaal hetzelfde scherm.
Uw Access-database bevat persoonsgegevens — klanten, patiënten, medewerkers, leden — en staat als .accdb op een netwerkschijf met onduidelijke toegang. Wie heeft er kopieën? Wie heeft wat gewijzigd? Bij een datalek of een AP-onderzoek staat u zwak. AVG vraagt om aantoonbare toegangscontrole en logging.
Werkt u in de zorg, dan vereist NEN 7510 aantoonbare logging van wie wat heeft gezien en gewijzigd. In de accountancy en financiële dienstverlening geldt de Wta met vergelijkbare eisen. Access biedt dat niet; een moderne web-app standaard wel, met onveranderbaar audit-log per record-mutatie.
De Access-applicatie is in de loop der jaren door één collega opgebouwd. VBA-macros, complexe queries, vele vorm-events. Als die collega met pensioen gaat, ontslag neemt of langdurig ziek wordt, weet niemand hoe het ding werkt. Dat is een operationeel risico dat zich pas openbaart wanneer het al te laat is.
U wil een klant-portaal koppelen, een mobiele scanner-flow, een koppeling met uw boekhouding of een ondersteuning voor meerdere vestigingen. Access kan dat in theorie nog wel, maar elke uitbreiding wordt een hack, en niemand garandeert dat de oude flows blijven werken. De omgeving is door de jaren te zwaar geworden voor het platform.
Een eerste gesprek waarin we begrijpen waarvoor de Access-database in uw werkproces dient, hoeveel gebruikers, welke pijnpunten en welke wensen er liggen. Daarna doen we een korte technische scan van het bestand zelf: aantal tabellen, relaties, formulieren, queries, rapporten en VBA-macros. Aan het eind ligt er een eerste schets van de migratie-scope en een idee van het juiste doel-platform.
Workshop met uw team plus interviews met een paar dagelijkse gebruikers: wat doet u nu in Access, wat zou u eigenlijk willen, en welke flows zijn business-critical? Tegelijk doen we een grondige analyse van het Access-bestand — macros uitlezen, queries doorlopen, data-relaties in kaart brengen. Aan het eind: scope, planning, schermflows, en het doel-platform per onderdeel.
We exporteren de data uit uw .mdb of .accdb naar Postgres, MySQL of SQL Server. Foreign keys die Access impliciet liet worden expliciet gemaakt, kolom-types geharmoniseerd, en data-kwaliteit gecontroleerd met een rapport van afwijkingen. Voor parallel-draaien zetten we een synchronisatie-script op zodat uw mensen nog even in Access kunnen blijven werken terwijl de nieuwe omgeving in opbouw is.
Elke twee weken een werkende build. We starten met de meest gebruikte flow — meestal één hoofd-formulier met de bijbehorende lookup-queries — en breiden in volgende sprints uit met overige formulieren, rapporten, audit-trail en de API-koppelingen. Uw key-users testen mee. De macros worden niet één-op-één vertaald, maar herzien tot duidelijke backend-logica met tests.
Een pilot-groep werkt twee weken parallel in de oude Access en de nieuwe omgeving. Verschillen worden gevonden en opgelost, schermen bijgeschaafd op feedback. Daarna training-sessies voor key-users, korte video's voor eindgebruikers, en go-live met een duidelijke roll-back-procedure als reservelijn. Access blijft nog tijdelijk read-only beschikbaar voor historische naslag.
Optioneel beheer-contract met monitoring, backups, security-patches en doorontwikkeling op wensen die in de discovery uit scope vielen. De omgeving groeit mee met uw werkproces.
Een Access-database vervangen valt uiteen in zes sporen. Eerst de data-export: tabellen uit het Access-bestand worden overgezet naar de doel-database (Postgres, MySQL of SQL Server, afhankelijk van wat uw IT-omgeving al draait). Access-eigen kolomtypes — AutoNumber, Yes/No, OLE Object, Hyperlink, Memo — mappen we naar serial, boolean, bytea en text. Foreign keys die in Access impliciet leefden (via lookups in formulieren) worden expliciet in het schema vastgelegd met bijbehorende constraints.
Daarna de forms. Access-formulieren zijn vaak een mix van invoer-velden, lookup-comboboxes, sub-forms en VBA-events. We herbouwen ze als web-UI in React, Vue of Astro, met dezelfde velden en validatie-regels maar in een ontwerp dat zich op meerdere schermgroottes laat bedienen. Sub-forms worden tabbladen of accordions, lookup-comboboxes worden zoekvelden met autocomplete, validatie gebeurt in de browser plus opnieuw aan de server-kant.
De reports gaan naar een BI-omgeving: Power BI als u Microsoft-georienteerd bent, Metabase voor zelf-hosted, of Looker Studio voor Google-omgevingen. Voordeel: rapporten zijn nu live, deelbaar via link en interactief filterbaar in plaats van compile-time. Het maandrapport dat eerst een uur Excel-werk was, wordt een dashboard dat altijd up-to-date is.
De macros zijn het delicate stuk. VBA-code kan van triviaal («wis dit veld bij een nieuwe record») tot complex («genereer een factuur-PDF met meerdere queries en mail die naar de klant») gaan. We documenteren elke macro, beslissen met u welke nog relevant zijn voor het nieuwe werkproces, en herbouwen die als backend-logica in TypeScript of Python met tests — zodat een latere wijziging niet stilletjes een berekening sloopt. De rest schrappen we bewust.
De queries — vooral de saved queries die in formulieren en rapporten gebruikt worden — worden API-endpoints. Een REST- of GraphQL-API geeft de data terug die voorheen in een query-resultaat zat. Daarmee opent u meteen de deur naar koppelingen met andere systemen: uw boekhouding, CRM, een mobiele scanner-app. Of een ander team kan op die API een eigen klant-portaal bouwen zonder de database zelf te hoeven aanraken.
Tot slot de cut-over. Niemand stapt graag in één keer over zonder vangnet. We werken parallel: Access blijft als naslag, een synchronisatie-laag spiegelt mutaties tussen oud en nieuw. Bij go-live wisselt de schrijfrichting; Access blijft nog beschikbaar voor historische naslag.
Microsoft Access overleeft in zes typen organisaties die we steeds vaker als opdrachtgever zien. MKB-administratie: kleine bedrijven met een eigen klant- of orderdatabase, vaak ooit door één medewerker met aanleg voor IT opgebouwd. Werkt voor de eerste honderd klanten goed, loopt vast bij de duizendste.
Kleine zorgpraktijken: tandartsen, fysiotherapeuten, kleine GGZ-instellingen. Patiëntenadministratie, afspraken en behandel-historie in een Access-bestand — een setup die nu botst op NEN 7510 en AVG. Vervanging is hier vaak niet optioneel meer; auditoren vragen om aantoonbare toegangscontrole en audit-trail.
Accountancy- en boekhoudkantoren: kleine kantoren met een eigen Access-database voor uren, klanten, dossiers en factuur-status, naast hun boekhoudpakket. De Wta-eisen rond dossier-vorming en audit-trail zijn strenger geworden; Access voldoet daar in de regel niet aan zonder veel handmatig werk.
Lokale overheid en publieke dienstverlening: gemeentelijke afdelingen, waterschappen, kleine uitvoeringsorganisaties — vaak met een register, vergunningen-database of interne handhavings-tool in Access. Hier komen AVG, Woo-verzoeken en interbestuurlijke informatie-uitwisseling samen.
Onderzoek, lab en R&D: universitaire onderzoeksgroepen, klinische labs, kleinere R&D-afdelingen die experimenten, samples en metingen in Access tracken. Vaak ontstaan vanuit een promovendus; twee jaar later staat de organisatie met een kennis-vacuüm. Een web-app met API biedt hier het bijkomende voordeel dat data direct in een data-pipeline kan landen.
Productie-tracking en kleine fabricage: MKB-productiebedrijven die hun werkorders, voorraad en kwaliteitscontroles in Access bijhouden. Pijnpunten zijn hier vooral mobiel (operators op de werkvloer hebben geen toegang) en integratie (boekhouding, ERP en Access lopen niet synchroon). Vervanging combineert hier vaak met een eerste integratie-laag richting koppelingen met overige systemen.
Het doel-platform hangt af van twee vragen: hoe specifiek is uw bedrijfslogica, en hoeveel zelf-aanpasbaarheid wil uw organisatie behouden? Voor generieke administratie-flows is een low-code-route zoals PowerApps met Dataverse of AppSheet met Google Workspace verstandig. Uw eigen mensen kunnen kleine wijzigingen later zonder ontwikkelaar doorvoeren. Nadeel: het ecosysteem bepaalt de spelregels — vendor lock-in is reëel.
Voor toepassingen waarin uw eigen logica leeft, kiezen we maatwerk. Postgres is onze standaard-database: open source, robuust, breed ondersteund. SQL Server als uw IT-team daar al mee werkt, MySQL in shared-hosting-scenario's. Front-end in React, Vue of Astro; backend op Node.js, Python (Django of FastAPI) of .NET — afhankelijk van wat uw eigen of toekomstige beheer-partij kent.
Voor de migratie zelf gebruiken we ODBC-koppelingen op het Access-bestand, een Python-script met pandas of een tool zoals mdbtools om de data eruit te trekken, en dbt of eigen SQL-scripts voor de transformaties naar het nieuwe schema. Voor BI: Power BI (Microsoft-georienteerd), Metabase (zelf-gehost) of Looker Studio (Google). Authenticatie via SSO op Azure AD, Okta of Google Workspace; magic-links of MFA voor externe gebruikers. En altijd een onveranderbaar audit-log — dat is het feature-verschil dat het meeste waard is.
Wat opdrachtgevers meestal willen weten voor we beginnen.
Een vrijblijvende kennismaking van een half uur. We luisteren naar uw huidige Access-flow en de wensen die er liggen, stellen gerichte vragen, en geven richting waar u iets aan heeft — ook als we uiteindelijk concluderen dat een lichte upgrade volstaat in plaats van een volledige vervanging.
Appfront gebruikt cookies en vergelijkbare technieken voor een goede werking van de website, voor analyse en voor marketing. Je kiest zelf wat je toestaat. Lees meer in ons privacybeleid.
