The database one person understands—rebuilt for everyone.
Replace a Microsoft Access database without losing what it knows. Your Access file holds years of rules nobody wrote down—we survey it, mirror it, and move it to a web platform the whole team can use.
Old and new run side by side until the numbers match, and the switch is rehearsed before it's real.
- Every table, query and macro surveyed
- Checked against the original
- Rehearsed switch, with rollback
// where the seams are
What an Access setup tends to look like
Most Access databases started as one person's fix for a real problem—then the business grew around them. That's why we don't replace one in a weekend. It goes through the one-system-at-a-time legacy modernization method: survey, mirror, side by side, switch.
A typical setup: a front-end .accdb (or an older .mdb) on a shared drive, tables split into a back-end file, saved queries nobody has opened in years, VBA behind the forms, and a macro someone runs at month-end. It works—until two people need it at once, the PC it lives on fails, or the person who built it moves on.
- Quoteswere a spreadsheet template, copied per job
- Orderswere entered on a form in the .accdb on the shared drive
- Inventorywas a linked table that locks when someone has it open
- Invoicingwas re-keyed into the accounting system
- Shippingwas typed again on the carrier's website
- Reportingwas an export pasted into a spreadsheet
Before: 5 places the data lives · re-entered by handAfter: 1 platform · entered once
// before and after
One file on a shared drive, or one platform your team shares
With the Access file
- One person understands the queries, and they're busy
- Two people editing at once means locked records, or worse, a damaged file
- Remote staff need a VPN, a remote desktop, or a copy that goes stale
- Orders, invoices and shipments are typed in two or three places
- Backups are whatever the shared drive happens to do
After the cutover
- The rules from the queries and VBA, written down and readable
- Everyone works in the browser at once, with roles and permissions
- Every change recorded—who, what and when
- Orders flow to invoicing and shipping without re-keying
- The old file kept read-only until you choose to retire it
Not ready for a call? Start with a free check of where your data gets re-keyed: Count your seams
// when the books are in Sage 100
Access runs the operation, Sage 100 keeps the books
A common pairing: orders, jobs or inventory in Access, and the books in Sage 100—or Sage 50 in a smaller office. The seam between them is usually a person re-keying invoices, receipts or item codes from one system into the other, every day, by hand.
We survey that seam first, because it is often the costliest one in the building. In the Blueprint we decide with you whether the new platform feeds Sage 100 the records it needs, or later takes over that part of the work as well. Accounting moves last, if at all.
// how it works
How we replace an Access database
The same four steps, with the specifics an Access file needs.
- 1
Survey
We open the file and inventory it: every table, relationship, saved query, form, report, macro and VBA module, and who uses which. Rules hiding in queries get written down in plain language.
- 2
Mirror
We build the new data model and copy the Access tables into it on a schedule. Your team keeps working in Access; nothing they do changes yet.
- 3
Side by side
The same orders go through both. We compare record counts, totals and printed documents until they match, and explain every difference before anyone relies on the new screens.
- 4
Switch
We rehearse the cutover on a copy of the file, then switch on a date you choose. The .accdb stays read-only, so rolling back is a decision, not a rebuild.
From the first call to the last switch
Each rung of the engagement has one job. Here is what each one means for an Access database.
What we cover
- What the database does, and who depends on it
- Where it meets the rest of your systems
- Whether to replace it now, later, or not at all
What we cover
- A walk through the tables, forms and reports that matter
- The seams traced to the systems around it
- A one-page map you can take to your leadership
What it includes
- A survey of every table, query, form, macro and module
- A map of where the data lives and who re-keys it
- A cutover plan with rehearsal and rollback
- The first automation to build once it's unified
- The measure each phase must move
How each phase runs
- The core records first, then the forms and reports around them
- A rehearsal on a copy before every switch
- Access kept read-only until you retire it
- Each phase measured before the next begins
The paid pilot
- One seam, taken from start to finish
- A fixed fee, agreed in the Blueprint
- Exit criteria written down before work starts
- Run in your own environment where your requirements call for it
- A decision at the end: continue to the next phase, or stop
Questions about replacing an Access database
Can we keep using Access while you build the replacement?
Yes. Access stays the system of record through the survey, the mirror and the side-by-side period, so your team keeps working the way it does today. It only steps back at the switch, and even then it stays read-only, so you can go back to it if something the rehearsal missed turns up.
What happens to our VBA, macros and saved queries?
We read every one of them before we build anything. Most VBA and macros encode business rules—pricing, approvals, numbering—so we write those rules down in plain language, confirm them with the people who use them, and rebuild them in the new platform. Queries nobody runs anymore are listed, then retired on purpose.
Will we lose our historical data?
Not by design: we copy every table, check counts and totals against the original, and keep the Access file read-only afterwards. The history is the point—it is years of how your business actually ran—so it moves during the mirror step, and you decide when, or whether, the file is finally archived.
Our books are in Sage 50 or Sage 100. Does that change anything?
It changes the order, not the method. When orders live in Access and the books live in Sage, the re-keying between them is often the costliest seam in the building. We map it in the survey, then decide with you whether the new platform feeds Sage or eventually takes over that part as well.
We're on FileMaker, not Access. Same approach?
Yes. A Claris FileMaker solution has the same shape: tables, layouts, scripts and calculations that hold years of business rules, often on one machine or one hosted file. We survey it the same way, mirror the data, run both side by side, and rehearse the switch, with FileMaker kept read-only afterwards.
How long does it take to replace an Access database?
It depends on how much the file does, which is why the survey comes first. The Blueprint turns what we find into a phased plan—an order, a rehearsal and a measure for each phase—so you see the whole sequence before you commit to building it. A small, self-contained file can move in a single phase.
Who does the work?
The owner of UniCorp leads every engagement, from the first call to the last switch, and is accountable for what ships. An AI-assisted engineering team builds it, and every change is tested before it reaches your systems. You meet the people doing the work before you commit.
Find your constraint. Get capacity back.
A free 30-minute call. We'll name the one constraint holding you back and the fastest path past it—whether or not you work with us.
30 minutes—bring the database, leave with a cutover order.