How do you migrate a company Access database?

Access database migration is the path a company takes to move data and application logic out of a Microsoft Access database that has become critical over time, toward a real data platform able to handle multiple concurrent writers and to talk without friction to the rest of the company's information system. The typical case is the .accdb file on a shared network folder running orders, inventory, or customer master data, built years ago by an outside consultant or an employee who no longer works at the company, with business logic embedded inside forms and VBA macros without a single line of supporting documentation. Access has often worked perfectly well for years, and keeps doing so elsewhere without issue: the risk lies not in the tool itself but in this one file, which quietly became critical to the business without anyone ever truly deciding so, or putting it in writing.

See also: Spreadsheet risk · The exposure that appears once a spreadsheet becomes the critical system for pricing, planning or payroll data.

Why Access hits its limit

Access was built for a single user or a handful of people, not for concurrent writes: beyond a small number of people updating the same file, locks and slowdowns become a daily occurrence. The file grows toward the 2 GB limit, and with size come more corruption episodes, often right during peak usage hours. Business logic lives inside forms and macros instead of a real database, so no version control exists: nobody can say with certainty which version is in production, or what a macro change would break. And above all, everything depends on one person: whoever built the file, often already gone, or the one colleague who still dares to open it in design mode.

What to keep and what to drop

Not everything needs a rewrite. The data almost always deserves saving: it is the company's history, and it belongs on a real relational database with integrity constraints Access never truly enforced. The business logic written in VBA needs case by case evaluation: part of it is still valid and should be rewritten in a maintainable language, part was a temporary fix that became permanent and should be let go. The realistic path proceeds in stages, exactly as in AS/400 modernization: first separate data from the interface, then move the data to a real database, and only then replace the interface, not the other way around. Whoever tries to redo everything at once, data and forms together, usually loses months and puts the same Access file back into production meanwhile, because the business cannot afford to wait.

When not to migrate

If an Access file serves five people, never grows, never locks, and nobody considers it strategic, migrating it is a cost without a benefit: it is the same reasoning behind technical debt, which only matters when it generates a real cost. The signal to act is not the file's age, it is the combination of operational criticality, growing concurrent write pressure, and dependence on a single person that nobody ever put in writing. When that combination exists, every month without a plan increases the risk that the migration gets forced by a file corrupted during peak usage hours.