Microsoft Access Modernisation

Your Access database knows how the business works. Twenty years of decisions are baked into it, including plenty nobody wrote down. That’s the reason it’s still running, and it’s also the reason replacing it costs more than anyone quotes for.

So we’d rather not replace it. Most of what people want from a new system, they can have on top of the one they’ve got: a web page for the staff who aren’t at a desk, an app for the engineers, documents that generate themselves, data going to and from the accounts package without anyone retyping it.

Ring ☎ and tell us what the business needs the system to do that it can’t. That’s usually a shorter conversation than it sounds.

What modernisation actually means here

The Access application stays the system of record. The people who use it all day carry on using it. Everything new plugs into the same data.

That means no retraining the office, no data migration weekend, no six-month build before anybody sees anything, and no single point at which the business bets itself on a new system going live.

What we add

A web interface for the people who aren’t at a desk. Sales entering orders from a customer’s office, managers approving things from home, anyone who currently rings the office and asks someone else to type it in. →web applications for existing systems.

Apps for staff out on the job. Engineers, drivers, fitters, surveyors. Job lists, sign-off, photographs, signatures, barcode and QR scanning, and working properly when there’s no signal, which matters more than anything else on that list. Data syncs back into the same database when they’re back in range. → mobile apps for existing systems

Portals for customers and suppliers. Order status, documents, previous jobs, invoices. Usually pays for itself in phone calls not taken. →customer portals and self-service

Email and documents out of the system. Quotes, order confirmations, job sheets, invoices, service reminders, chase letters. Generated from the live data, sent automatically, logged against the record so anyone can see what went out and when.

Proper file and document handling. Attachments, drawings, photos and certificates stored outside the database rather than bloating it, with links from the record, version history and a clear audit trail of who added what. This is also the single fastest way to stop an Access back end marching towards its size limit.

Integrations, so the same number gets typed once. Accounts software, couriers, payment providers, e-commerce, EPOS, other people’s systems. Via APIs where they exist and file exchange where they don’t. →Access integration and APIs

Reporting people will actually look at. Live dashboards and scheduled reports instead of exports into Excel that somebody reformats every Monday. → reporting and business intelligence

Data on SQL Server or Azure underneath it all. Often the first step, because most of the above works better with a proper database engine behind it. → Access migration and upgrades

Free review of your existing application

[IMG-2] — Right-aligned, half column. A page of genuine analysis output: object inventory, table relationships, a dependency or query map. Redacted. Shows the review is real work rather than a sales call.
Alt: Microsoft Access application review and analysis report

Before anyone talks about building anything, we’ll go through the application you have, free of charge.

Send us a copy through our secure upload and we’ll look at the whole thing: how it’s structured, where the business logic sits, what state the code and data are in, what’s holding it together, and what would need to change for each of the options above. Then we’ll ring you and talk through what we found and what we’d suggest. You’re free to do nothing with it.

send us your database for review

The questions worth asking first

• Is it better to extend the life of what you’ve got, or replace it?
• What does keeping it running actually cost over the next three years, including the workarounds?
• Which parts of the business are currently doing by hand what the system should be doing?
• What would have to happen for this to go wrong, and can it be undone?

We’ll give you our answer to all four, including when the answer is that you don’t need us yet.

How we build it

Straight answer to the obvious question, since you’re being asked to trust an Access consultancy with a mobile app.

• Web: .NET / C# and Node.js (NestJS), talking to the same SQL Server or Azure SQL data
• Mobile: React Native where one app needs to cover iOS and Android, native Swift or Kotlin where the hardware matters (scanners, cameras, offline-first, background sync)
• Data: SQL Server, Azure SQL, and the existing Access application kept in step throughout
• Integrations: REST APIs, webhooks, scheduled exchanges, and the older file-drop methods where that’s all the other system offers
• Infrastructure: Azure, defined in code with Terraform so environments are repeatable and nothing lives only in somebody’s head

In stages, and reversible

Nothing here needs a big-bang cutover.

We pick the thing that hurts most, build that, put it in front of the people who’ll use it, and get it working properly before starting the next one. The Access system carries on running throughout. If you stop after phase one, phase one still works and still earns its money.

Related case studies