Inherited an Access database that runs the business?

The database may be old. The business function is not.

Access systems often start as practical local tools: a quoting database, a scheduling tracker, a job log, a small CRM, an inventory worksheet that grew legs. Years later, the person who built it is gone, the office still depends on it, and nobody wants to be the one who breaks it.

That is not a failure of the people using it. It is an engineering continuity problem.

• The original builder retired, left, or cannot be reached.
• Only one workstation can safely open the file.
• Reports or forms are edited by copying old ones and hoping.
• The database locks up, corrupts, or slows down under normal use.
• Excel exports, manual re-entry, or email attachments are part of the workflow.
• Everyone agrees it should be replaced, but nobody knows what it actually does.

What an initial engagement looks like

• Artifact inventory
• Tables, fields, relationships, and row-count summary where extractable
• Forms, reports, queries, macros, and VBA inventory where available
• External dependency and linked-table notes
• Risk and fragility findings
• Questions for staff who know the workflow
• Stabilization or migration options

The first service product is not a rewrite. It is reliable understanding.

When this is worth doing

• The database supports billing, scheduling, inventory, field work, compliance, records, or customer operations.
• The system is still used, even if everyone dislikes it.
• You need to preserve business continuity while considering replacement.
• You want a responsible technical read before asking for a rebuild quote.

• You only need a one-line Access formula answer.
• You want someone to make risky production changes without a backup.
• You want to upload private business data into public AI tools.
• You need legal, tax, or accounting advice rather than technical systems work.