Rescue or replace an Access system without guessing first

The person who built the .accdb has left. The file locks. Or Excel is doing the real reporting. We will tell you whether to keep Access, put SQL Server under it, or replace the front.

Book a free 30-minute discovery callTalk through your Access system

Australian .NET team. We look at the file before anyone talks about a rebuild.

Still running Access?

The database still works. That is why it has been left alone.

Most of the Access and Excel-VBA systems we hear about were built years ago for one team, on one share. Then the person who understood the VBA left, and copies of the file started appearing on desktops.

You might recognise one of these:

  • Nobody on the team wants to open the VBA
  • The file locks when a second person opens it
  • Staff work on copies, and nobody is sure which one is true
  • Excel is the real reporting layer
  • Someone said “just put it on the web”
  • You are not sure whether to keep Access or leave it

You do not need a new brand, or a platform pitch. You need a clear read on the system you already have.

Why these databases stall

Access is still a real Microsoft product. The problem is rarely “Access died”. It is a file that one person understood, shared over a network, with VBA that grew into the business.

One developer

Locked file

VBA

Excel sidecar

One developer.

The person who built the .mdb or .accdb has left. The remaining team will not open the modules. Forms and reports still look like Access. The rules live in VBA.

The file locks.

Access is a file. When two people need it at once, or someone leaves it open, the database locks. Copies appear. Remote staff cannot use the share the way the original room could.

VBA is the product.

The data can move to SQL Server. The code is a separate job. Rescue, tuning, and reports can stay in Access. Integration and a .NET replacement cannot treat the modules as a file copy.

Excel is the sidecar.

Pivots, board numbers, and the workbook someone refreshes by hand are part of the system, even if nobody listed Excel as an application. That work has to be in the assessment.

None of that makes the data or the workflows worthless. It does mean “just put it on the web” is usually the wrong first move.

How we work

We start with the file, not with a destination.

1

Look at what you have

The Access file or files, the VBA, linked Excel, who can open it, and whether it already talks to SQL Server. We will tell you what is worth keeping, and what is not.

2

Decide the job

There are three honest outcomes. We recommend one, not all three.

3

Do the work in stages

Data, reports, and the workflows people actually use come across. Unused forms do not. Rescue and tuning stay in Access when that is the job. Integration, data migration, and a SQL Server or cloud move are staged so production is not taken down to guess.

4

Hand it back so the next person can run it

Source, a short record of what changed, and a system someone else can understand.

Three honest outcomes

  • Keep and harden Access : rescue a broken file, tune it, fix reports, and make the VBA something the next person can touch
  • Move the data to SQL Server and keep the front : Access or Excel stays as the client; the engine is SQL Server, including cloud-enable when remote staff cannot keep using a locked file
  • Replace it with a .NET app : migrate the data, reimplement the rules, and retire the file when the front cannot come with you

We will not tell you Access is perfect. We will not tell you every file has to become a website. If you already know you want to stay on Access forever, an Access-only shop may be a better fit. If you want an honest fork in the road, talk to us.

What we need for the first call

A copy of the file, or a screenshot and a sentence about what is breaking, is enough to start.

  • Whether it is Access, Excel-VBA, or both
  • Whether the file locks, corrupts, or only one person will touch it
  • Whether data already lives in SQL Server, or it is still in the Access file
  • Linked Excel, reports, or other systems it has to talk to
  • Who still has the password, and whether the last developer is gone
  • What “done” looks like: keep Access, move the engine, replace the front, or get a clear picture first

The first call is 30 minutes. You leave with a recommendation you can take to a manager, not a rebuild estimate pulled from thin air.

Related work

There is no published CoSource Access case study. We will not invent one.

We have taken over and modernised ageing Microsoft systems for Australian organisations, including work with Data#3, Hastie, NESS, and NSW Health (TESL). That is related database and .NET work. An Access or Excel-VBA system still starts with its own assessment.

FAQ

Can we keep Access and only fix the backend?
Yes. Moving the data to SQL Server and keeping the Access front is one of the three outcomes. We will not pre-sell a rewrite if the file can be hardened.
Do we have to replace it with a website?
No. Access is still a real product. Leaving only makes sense when the file, the locking, or the VBA will not come with you.
What happens to the data and the VBA?
Data can migrate. VBA is rewritten or retired, not pasted into a new app. Reports and Excel workbooks are part of that pass.
What if the last developer has gone?
That is common. Bring the file.
We only have the .accdb and an old PC.
That is common. Bring that.

Talk through the Access system you already have

Thirty minutes. Bring the file, or a sentence about what is breaking. We will tell you whether to keep Access, put SQL Server under it, or replace the front.

Book a free 30-minute discovery call