Your Access database isn't the problem. Its dependencies might be.

A manufacturer asks for a replacement database because the current one is slow. During a walkthrough, the slow step turns out to be a report that pulls linked records across a network. Meanwhile, the same application contains a pricing exception that nobody has written down elsewhere.

That is an illustrative situation, not a client case study. It explains why the replacement decision should follow an investigation. The symptom tells you where the work hurts. It does not yet tell you which part needs changing.

Our earlier guide explains what to map before replacing Access. This article takes the next step: how to compare the options once those dependencies are visible.

Separate the application into layers

Think about four layers: the records, the business rules, the interface and the surrounding workflow. A table stores a claim. A query calculates an amount. A form guides an approval. A spreadsheet export supplies a monthly review.

Changing the records does not automatically fix the approval process. Rebuilding the interface does not automatically preserve the calculation. Put each dependency against the layer it actually belongs to before estimating a migration.

For example, a customer-specific price might live in a table, in VBA or in a person’s interpretation of a report. Those require different preservation work. Ask someone to demonstrate the result, then identify how the application produces it.

Compare three realistic paths

Path	When it is worth assessing	What still needs checking
Repair and document	The workflow fits, but a specific query, report or dependency causes interruptions	Whether the repair addresses the cause and who will maintain it
Move the data back end	Existing forms remain useful, but data management or concurrency needs change	Linked tables, permissions, query behavior and operating responsibility
Replace part or all of the application	Users need a different workflow, access model or interface	Business-rule coverage, migration, training and cutover

Microsoft documents a path that retains Access application logic while using a database server for data management in its Access deployment guidance. That makes a partial modernization a legitimate option to assess. It is not evidence that it will suit every application.

Know what a migration utility does not replace

Microsoft’s Access-to-SQL Server migration guide explains that its migration assistant does not convert forms, reports, macros or VBA modules. Those objects need separate consideration.

A successful table transfer therefore answers only part of the business question. Can users still complete a claim? Does a credit calculation reconcile? Does the downstream export still mean the same thing?

Choose representative records with the people doing the work. Include a routine transaction, an exception, a reopened case and a historical record. Record the expected result before changing the application.

Make the decision reviewable

For each option, describe what stays, what changes, what must be tested and what remains uncertain. Include licensing, support, backup and the practical ownership of the new arrangement. A smaller project can still introduce a new operational responsibility.

Then agree the reason for choosing a path. That might be a measured reporting bottleneck, a need for controlled multi-user access or a workflow the existing interface cannot reasonably support. A dislike of the application’s age is a weaker basis for a decision.

Start with one dependency

You do not need a perfect inventory to begin a conversation. Bring one task that causes trouble, the systems it touches and the result that must remain correct. Keep customer records and credentials out of the initial description.

Talk to us about Access modernization. We can help identify which dependencies need preserving before choosing what to repair, migrate or replace.