Microsoft Access databases
Forms, queries and macros built up over years by someone who has since moved on.
Microsoft Access Replacement
Get the business off one PC under someone's desk.
The Access database still works, which is exactly the problem — it works well enough that nobody replaced it, and now the company runs on a file that one person understands and only one person can edit at a time.
Everyone in
at once
at once
Data brought
across intact
across intact
Access control
and audit
and audit
Reports without
exporting
exporting
File lockedSomeone else has it open
Copy on a desktopNobody knows which is current
One person knows itAnd they are retiring
The problem
It is not broken. It is just one bad day from being broken
Nobody replaces a working system for fun. The trigger is usually a resignation, a failed hard disk, an auditor's question, or the moment two people need the same record at the same time and one of them loses an hour of work.
- Only one person can edit at a time, so the rest of the team queues or keeps a copy of their own.
- The file lives on a desktop or a shared drive, and the backup is whatever somebody remembered to copy.
- One employee wrote the macros and understands the logic. Nothing is documented.
- It cannot be reached from home, from a branch or from a phone, so work waits until someone is at that desk.
- There is no record of who changed what, which becomes a real problem the first time an auditor asks.
Built for outgrown systems
When the tool that got you here cannot take you further
Access and Excel are genuinely good at what they do. The problem is never the software — it is that a single-user tool ended up carrying a multi-user business.
Shared spreadsheets
A workbook with twelve tabs that three departments edit and nobody dares restructure.
Unsupported software
A package whose vendor has closed, or that will not run on current Windows.
Single-site systems
Software that works in head office and cannot be reached from a second branch.
Departmental tools
Something built by a capable staff member that quietly became business critical.
Ageing web systems
An old application on a PHP or framework version that no longer receives security fixes.
Rewriting is not automatically the answer. Sometimes the honest fix is smaller: move the Access back end onto a proper database server, or lift the spreadsheet into a hosted tool. We will tell you when that is the sensible option, because it costs you less and works sooner.
A rebuild earns its place when several people need the data at once, when the logic has to change and nobody dares touch it, or when the business cannot afford the day that file goes missing.
From old file to live system
How a replacement actually happens
Six steps. The old system keeps running until the last one — nobody is asked to switch on faith.
Read it
We open the database itself: tables, relationships, queries, forms and every macro.
Write it down
The rules buried in macros and habits become a document you can actually read.
Clean the data
Duplicates, orphaned records and free-text fields that should have been lists.
Rebuild
Same job, web system: multi-user, permissioned, reachable from anywhere.
Run both
A period of parallel running, with the same work entered twice and the outputs compared.
Retire
The old file is archived read-only, not deleted, and the team moves across.
Expect to find rules nobody remembered. Every one of these projects turns up a calculation, an exception or a workaround that exists only because of something that happened years ago — and that discovery is most of the value of stage two.
What you get back
Main modules and functions
The replacement keeps what the old system did well and adds the things a single-user file could never offer.
Your data, migrated
Every record brought across with its history, checked against the original counts before switchover.
Forms & records
The screens people already know, rebuilt with validation so bad data cannot get in.
Concurrent use
The whole team working at once, from the office, a branch or home, with no file locking.
Roles & permissions
Who may see, edit, approve or delete — instead of everyone having full access to everything.
Audit trail
Every change recorded with who and when, which is usually the first thing an auditor asks for.
Reports & exports
The reports you used to build by exporting to Excel, generated in the system on demand.
Backup & recovery
Automatic backups with a tested restore, rather than a copy somebody makes on Fridays.
Integration
Links to accounting, email or whatever else the old system could only reach by re-typing.
Documentation
The written rules and a handover pack, so the knowledge no longer sits with one person.
From a live build
Screens from a records system we built
From PermitPro, an agency back-office system where candidate records, statuses and documents live in one shared web application instead of a desktop file. Screens showing personal records have been left out.
Implementation
Typical implementation
Six stages. This is the one project type where we ask for a copy of your existing system before quoting — anything else would be a guess.
System archaeology
We take a copy of the database and go through the tables, queries, forms and macros ourselves, then sit with the person who uses it daily.
Output: written rules and a field inventoryData audit & clean-up
Duplicates, orphaned rows, dates stored as text, and the free-text columns that were meant to be lists. You decide what gets fixed and what gets carried across as-is.
Output: clean-up decisions with countsDesign & sign-off
Screens designed to be recognisable to the people who used the old ones, because familiarity is what makes the switch survivable.
Output: signed-off screens, build scheduleRebuild
The core records and daily workflow first, then the reports and the awkward exceptions that only appear at month end.
Output: test system, updated fortnightlyMigration & parallel run
Data moved across and reconciled against the original, then a few weeks of running both systems and comparing the outputs before anyone commits.
Output: reconciliation report, signed UATSwitchover & archive
The old file is made read-only and kept, not deleted. Training, an SOP, and support through the first month end.
Output: live system, archive, SOP
Timeline
Three to five months, depending on what we find
A tidy Access database with a dozen tables sits at the short end. Twenty years of accumulated macros and exceptions sits at the long one, and only stage one can tell you which you have.
Month 1Month 2Month 3Month 4
System archaeology
Data audit & clean-up
Design & sign-off
Rebuild
Reports & exceptions
Migration & parallel run
Switchover
The parallel run is the part clients want to cut, and the part we argue hardest to keep. Running both systems for a few weeks is the only way to prove the new one produces the same numbers — and it is far cheaper than discovering a wrong calculation after the old file has been switched off.
Client feedback
From a client we delivered an implementation for
Thanks to UNO and Team! Truly it has been a pleasure working with you on this implementation. We are truly satisfied by the professionalism you have demonstrated all this time and the quality of work, plus the effort of your entire team. Kudos guys!