How to Audit a Microsoft Access Application Before Replacing It

The most expensive Microsoft Access replacement mistakes usually begin with a tidy inventory of tables. It looks complete until someone tries to close the month, print an exception report, or import the spreadsheet that arrives every Friday. The database schema tells only part of that story.

An application audit should produce a map of the work, the rules embedded in the application, and the evidence needed to prove a replacement is safe. It is not a request to document every button for its own sake.

Follow the work before opening the object list

Sit with people who use the application. Ask them to complete a routine transaction, a correction, and one less common task such as a month-end close. Record the starting data, decisions, screens, outputs, and people who approve the result. Note the steps they perform outside Access. A spreadsheet or email may be part of the actual system even if it is not in the .accdb file.

For each workflow, write down the expected result and a sample record that can later become an acceptance test. This is more useful than a screenshot collection. Our Microsoft Access migration testing article covers how to turn walkthroughs into repeatable checks once the target is chosen.

Inventory the application in layers

List the database files and who has copies. Identify which tables are local and which are linked. Then trace forms and subforms to their queries and table updates. Review macros and VBA modules for calculations, validations, navigation, imports, and exports. A button labeled 'Post' can contain the business rule nobody remembers to mention.

Capture report definitions and their consumers separately. Include filters, grouping, calculated fields, output format, and whether someone manually edits the exported file. Finally, list connections to Excel, Outlook, shared drives, ODBC sources, APIs, and scheduled jobs. Microsoft maintains Access developer documentation for the application model; use it to check mechanisms, not to assume your particular database uses them.

Score risk, not just object count

Tag each workflow by business criticality, frequency, data sensitivity, owner, and testability. A dormant form can be retired with a documented owner decision. An infrequent interest calculation may need careful parallel results. Mark every rule whose owner is unknown as an open question, not as a requirement you silently infer from code.

Keep a small evidence register: sample input, expected output, current location of the rule, responsible reviewer, and proposed treatment. The result should tell the project team what to preserve, what to redesign, and what can be retired.

Turn the audit into a decision

At the end, compare a stabilization or database bridge with a full replacement. Our bridge strategy explains why keeping the frontend temporarily may reduce change risk. The Access banking case study is a useful example of reverse engineering important financial behavior without original documentation.

An audit is done when a technical team can estimate the next phase and a business owner can challenge its assumptions. A thick document no one can use is not the finish line. If you need help mapping an Access application before replacing it, start with a modernization assessment.