IT consultants are often hired to “fix” an Access database that has outgrown its limits. Many are competent and honest. But the consulting business model creates incentives to downplay certain realities. Here are the things you should know before you sign the contract.

“It’s a Simple Migration” Is Never True

The sales pitch usually sounds like this: “We’ll move your data to SQL Server, update the connections, and everything will work the same. Should take a couple of weeks.”

What actually happens: the data moves fine, but then the forms break. The VBA code throws errors. Queries return different results. Reports are blank. Users call to say the new system lost their data (it did not — the form is just not displaying it correctly).

The data migration is the easy part. It is maybe 10% of the total effort. The other 90% is testing, fixing, and retesting the application layer — the forms, queries, VBA code, and reports that interact with the data. No migration tool automates this part.

What to ask: “What is your plan for testing and fixing the forms, queries, and VBA code after the data is migrated? How many hours is that scoped for?”

Nobody Knows What the Application Actually Does

Here is a scenario that plays out constantly: a consultant is hired to migrate the database, and nobody in the organization can fully explain what the Access application does. The person who built it retired three years ago. The documentation, if it exists, is out of date. Current users know their own workflow but not the system as a whole.

The consultant looks at the tables and forms and makes reasonable assumptions. They migrate the data, fix the obvious errors, and declare the project complete. Six weeks later, someone discovers that the quarterly commission calculation is wrong because it depended on a VBA function that was silently broken during migration.

This is not the consultant’s fault, exactly. They cannot test what they do not know about. But it is your risk.

What to ask: “How will we identify all the business logic in the current application? Who will verify that every calculation and process works correctly after migration?” If the answer is “we’ll test the major functions,” push back. The major functions are not the problem — the obscure ones that only run quarterly or annually are where the bugs hide.

The Estimate Is Too Low

Migration estimates are almost always too low, for understandable reasons. Higher estimates lose bids. The consultant believes they can work efficiently. They have done migrations before and it went smoothly (survivorship bias — they remember the easy ones).

The reality is that every Access database is different. The number of forms and tables gives you a rough idea of scope, but the complexity depends on the VBA code, the query design, the data quality, and the undocumented business rules. These are unknowable until you start doing the work.

Industry data suggests that Access migration projects exceed their original estimates by 50% to 100% on average. A project estimated at 80 hours commonly takes 120 to 160 hours.

What to ask: “What contingency is built into this estimate? What happens when we discover issues that were not in the original scope?” Get this in writing. A consultant who is confident in their estimate should be willing to put a cap on overages.

Data Cleaning Is Your Problem

Migration tools move data from one format to another. They do not fix the data itself. And Access databases are notorious for data quality issues:

A consultant can write scripts to clean data, but they cannot make judgment calls about your business data. Is “John Smith” at “123 Main St” the same customer as “J. Smith” at “123 Main Street”? Only someone who knows your business can answer that.

Data cleaning often consumes more time than the migration itself. Budget for it, and plan to have someone from your team involved who knows the data.

What to ask: “What data quality assessment is included in the migration plan? What cleanup is the consultant’s responsibility, and what is ours?”

You Need a Rollback Plan

What happens if the migration goes badly? Not a catastrophic failure — those are obvious. What if the new system works but is noticeably slower? What if users cannot adapt to the minor changes? What if an important calculation is wrong and nobody notices for a month?

A good migration plan includes the ability to roll back to Access for a defined period after cutover. This means:

Many consultants do not include rollback planning because it implies the migration might fail. But the purpose of a rollback plan is not pessimism — it is risk management.

What to ask: “What is the rollback plan if we need to go back to Access? For how long after cutover can we roll back?”

The Project Does Not End at “Go Live”

Consultants are incentivized to reach a defined completion point so they can move on to the next project. That completion point is usually “the system is running and users can access it.” This is go-live, and it is the beginning of the hardest phase, not the end of the project.

After go-live, you will discover: - Edge cases that were not tested - Reports that produce slightly different numbers - Queries that are slower because of the ODBC layer - Users who find workarounds instead of reporting problems - Seasonal processes that were not tested because they only run at year-end

Budget for at least four to eight weeks of post-migration support. This should include the consultant being available to fix issues as they are discovered, not just “available for questions.”

What to ask: “What post-migration support is included? For how long? What is the response time for production issues?”

You Might Not Need a Consultant

Here is the part no consultant will tell you: for a straightforward Access-to-SQL-Server migration where you are keeping the Access front-end, you might be able to do it yourself.

Microsoft’s SQL Server Migration Assistant (SSMA) handles the data migration. The ODBC linked table setup is well-documented. The common post-migration issues (Boolean values, date formats, query syntax) are predictable and well-known.

If your Access application is relatively simple (under 30 forms, under 1000 lines of VBA, no complex calculated fields), and you have someone on your team who is comfortable with Access and willing to learn basic SQL Server administration, a self-service migration is feasible.

What you would save in consulting fees, you would spend in your own time. But you would also gain knowledge of your own system that no consultant will leave behind.

The honest assessment: Hire a consultant if your application is complex (100+ forms, heavy VBA, complex reporting), if you need it done quickly, or if nobody on your team has time. Do it yourself if the application is simple and you have someone willing to learn.

The Bottom Line

Consultants provide real value when they bring experience, methodology, and efficiency to a complex project. But their incentives are not perfectly aligned with yours. They want to close the project; you need the project to succeed long-term.

The best thing you can do is go into the engagement informed. Know what questions to ask. Know where the hidden costs are. And know that the most important phase of the migration is the testing that happens after the data moves — not the data move itself.