Somewhere in your business there is an Access database or a workbook that runs a real process, was built by someone who has left, and lives on one machine that nobody is allowed to turn off. We move systems like that onto the web without rewriting them from scratch — the data comes across, the rules come with it, and you get permissions, auditing, backups and an API you never had.
Modernise our Access database.
Access was a good answer to a real question. Someone in the business needed a system, IT could not deliver one in a useful timeframe, and Access let them build something that worked. The problem is not that decision — it is that the thing they built became load-bearing and then stopped being maintainable.
What breaks is rarely the data. It is everything around it. A file-based database was never designed for concurrent editing, so multi-user access is a permanent low-grade risk. There is no meaningful permission model, so anyone who can open the file can see and change everything in it, which is a genuine problem the moment the data includes people. There is no change history, so an error found in June cannot be traced back to who made it in March. And because it is a file, backup and recovery are a matter of habit rather than infrastructure.
The reason these systems survive so long past their sell-by date is that replacing them looks like a rewrite. The logic is real and hard-won, the fields have meanings that live in someone's head, and a quote for a ground-up rebuild makes carrying on look sensible for another year. That calculation is what we are trying to change.
We start from the data rather than the interface. The spreadsheet or the exported Access tables go in, and easy-create mode detects field types and builds a proper datastore from them — with validation, indexing, row-level auditing and permissions attached from the first day. That is usually a matter of hours, not weeks, and it gives you something real to look at very early.
From there the forms and browse screens are generated over that data rather than hand-built, so the tedious part of the rebuild — every add, edit, delete and list screen — is not a cost line at all. What we spend time on is the part that was only ever in the old system's macros and in your team's heads: the validation rules that stop bad records, the calculations that have to be right, the statuses a record moves through, and who is allowed to do what.
The result is the same system, doing the same job, reachable from a browser. It is multi-user by design rather than by tolerance, every change is attributable, deleted rows go to a recoverable area instead of vanishing, and there is a REST API over it for the day something else needs to read it.
Export the existing tables and drop them in. Field types are detected automatically and become a real datastore with indexes and validation. Where the old system had lookup tables held together by convention, they become proper linked fields with dropdowns that cannot hold a value that does not exist.
Row validation covers the checks that span several fields — the ones the old system either enforced in VBA or did not enforce at all. Calculated fields take over the arithmetic, computed on the server on every save, so a total cannot be edited into disagreeing with the lines it came from.
Security groups replace the all-or-nothing access a shared file gives you. Permissions run down to individual fields, so a manager can see a salary column and a coordinator working in the same record cannot. This is usually the first moment the business notices the system has genuinely changed category.
Whatever the old system did through a sequence of forms and someone remembering the order becomes an explicit workflow, with stages, assignment and the option for an approval step that an authoriser completes from an e-mail link.
The report builder joins related tables for you, so the reports that used to be a query someone wrote and nobody else understood become something your own team builds and schedules. Scheduled tasks e-mail the recurring ones out on their own.
Nothing here is written specially for this use case — it is the same platform every ActiveManage application is built from. The full feature list is on the platform page.
| Feature | What it does | Why it matters here |
|---|---|---|
| Easy-create mode | Drop a spreadsheet in; smart field-type detection converts it to a datastore. | This is what makes the migration a project rather than a rewrite. Your data is in a real system on day one. |
| Data Import System | File imports with field mapping, data translation and five methods: Import All, Import New Only, Delete, Delete Missing and Update Existing. | Migrations are never one clean import. Update Existing is what lets you re-run a load after a correction without duplicating everything. |
| Auditing | Every add, edit and delete records what changed, when and by whom, with one-click rollback to a previous version. | The single biggest thing a file-based database cannot give you, and the one most often demanded the moment anyone from compliance looks at the system. |
| Security groups | Unlimited groups, users in several at once, permissions down to individual fields. | Replaces "everyone who can open the file can do anything in it" with a model you can actually describe to an auditor. |
| Deleted items | Deleted rows move to a recoverable area rather than disappearing. | The accidental delete that used to mean restoring last night's copy of the file and losing a day's work. |
| API engine | Ready-made create, read, update and delete endpoints over your data, with the same permission rules as the interface. | The old system was a dead end for integration. This one is not. |
Data in, structure agreed, and a working system you can open and click through. This happens early and deliberately — it is much easier to say what is wrong with something on screen than to review a specification.
The rules, permissions and process go on top, with your team using it against real data while it is being built rather than at the end.
It is ordinary platform configuration, so your own people can open it and change it afterwards. That is the point of doing it this way rather than commissioning something you can never touch.
No. The existing tables are exported and imported with field mapping, and the import can be re-run with Update Existing after a correction without creating duplicates. Nothing is re-keyed by hand.
It gets read and translated into platform features rather than carried across. Most VBA in these systems is doing one of four things: validation, calculation, moving a record through a process, or producing a report. Those are validation rules, calculated fields, workflows and the report builder respectively. Genuinely unusual logic can be written as a custom function.
Yes, and you generally should. The import can be re-run to bring across anything added in the meantime, so there is no freeze period and no big-bang cut-over weekend.
UK-hosted by default. The platform is UK-built and used by NHS trusts and public-sector bodies, so data residency and the paperwork that goes with it are familiar ground rather than a special request.
Sometimes not, in year one. It is usually cheaper over five, because there is no per-seat licence that grows with your headcount and no annual renewal for software that fits you less well each year. If an off-the-shelf product genuinely fits your process, buy it — we will tell you so.
Tell us what you are trying to fix and we will tell you whether this is the right shape for it — including when it is not.