Web Applications for Existing Systems

Your system works. It just only works in one building.

Sales are ringing the office to check stock. Managers approve things by email because they can’t get at the screen that does it. Engineers write jobs on paper and someone types them up on Monday. Anyone working from home is either on a VPN that crawls or is being read figures over the phone.

You don’t need a new system for that. You need a way in from a browser.

☎

What this actually is

[IMG-1] — Layered diagram. Existing database at the bottom, marked “stays as it is”. The existing desktop or Access application on the left, marked “keeps working”. A new browser interface on the right, arrows to the same database. One caption: both look at the same data.
Alt: Browser interface added alongside an existing desktop application

We build a web application that works against the database you already have.

The office carries on using the system they know. The people who can’t get to it use a browser — laptop, tablet, phone, anywhere with a connection. Both are looking at the same records, live. Nothing is copied, synchronised overnight or reconciled afterwards.

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

And it’s usually a fraction of what replacing the system would cost, because the expensive part of any business system — the years of accumulated rules about how your business actually works — is already built and already correct.

What people use it for

Staff who aren’t at a desk. Sales entering orders from a customer’s office. Site managers checking deliveries. Anyone currently ringing the office to ask someone else to type something in.

Remote and hybrid working. Proper access from home without a VPN and without a remote desktop that’s painful over a domestic connection.

Multiple sites. One system, reachable from all of them, instead of a copy per branch and a reconciliation problem.

Approvals and sign-off. The manager who holds up every order because the only screen that authorises them is on a PC they’re not sitting at.

Read-only access for people who only need to look. Reception checking an order status, finance looking at a job, directors wanting a number without asking anyone for it.

Customers and suppliers. A separate question, and usually the next one → customer portals and self-service

If your system is Microsoft Access

Worth being direct about this, because there’s a lot of outdated advice around.

You cannot put Access itself on the web. Access web apps and Access Services in SharePoint were retired by Microsoft years ago. If someone has offered you that, it doesn’t exist.

What does work, and works well:

1. Move the data to SQL Server or Azure SQL, keeping your existing Access front end pointed at it. The office sees no difference. → Access migration and upgrades
2. Build the web interface against that same SQL back end, covering the parts people need from outside.

Two things worth knowing. The first step is usually worth doing on its own — it fixes the corruption, locking and speed problems that come with several people in a shared Access file anyway. And you don’t have to web-enable the whole system: most businesses need four or five screens out of eighty.

→ Access modernisation

Security, which is the real question

[IMG-2] — Right-aligned. A sign-in screen with MFA, or an access log showing who did what and when. Redacted. This block is answering an anxiety and a picture helps.
Alt: Secure authentication for a business web application

You’re about to make a business database reachable from the internet. That deserves more than a login box.

• Microsoft Entra ID sign-in, so people use the account they already have and leavers lose access when their account is disabled — not whenever somebody remembers
• MFA and conditional access on anything that touches real data
• Access by role and by group, so the web interface exposes what that person is allowed to see and nothing else. It does not need to expose the whole system.
• The database itself never exposed. The web application talks to an API; the database sits behind a private endpoint and isn’t reachable from the internet at all.
• Everything logged — who looked at what, who changed what, when. That’s the audit trail, and it’s the first thing anyone asks for after an incident.
• Encrypted in transit and at rest, with certificates that renew themselves rather than expiring on a bank holiday

For anyone with Cyber Essentials, ISO 27001, DSPT or client security questionnaires, this is the part that gets examined. We build to answer it, and we can help with the paperwork → Azure and cloud

How it’s built

• Web: React and Next.js
• Back end and APIs: .NET and C#, or Node.js and NestJS
• Data: SQL Server or Azure SQL, with your existing Access or desktop application still attached to it
• Hosting: Azure App Service or Container Apps, or your own servers if you’d rather
• Infrastructure defined in Terraform, so environments are repeatable and you own the definition

It works on a phone, because roughly half the people who need this are holding one.

In stages

We take the thing that hurts most — usually one screen and one workflow — build that, put it in front of the people who’ll use it, and get it working properly before starting the next.

The existing system runs throughout. If you stop after phase one, phase one still works and still earns its money.

how we work

Mobile Apps for Existing Systems

When it needs to work on site, offline, with a camera or a scanner.

Find out more...

Customer Portals & Self-Service

The same idea, pointed at your customers.

Find out more...

Access Migration & Upgrades

The usual first step for an Access system.

Find out more...