Approach
First the existing database is analysed: tables, relationships, forms, reports and the macros behind them. The real business logic often sits not in the tables but in the VBA code behind them. If that was never documented, trouble is only a matter of time.
The data moves into a proper database, the interface is rebuilt as a web application, and the logic moves to a server everyone can reach. From then on, every update to features and interface is simply rolled out.
The switch then happens in steps. A first version runs alongside the old database until every workflow works in the new application. Only then is Access switched off.
What drives the effort
- How many forms and reports are in use
- How much logic lives in VBA and how readable it is
- Connections to other systems through imports or exports from Access
- Whether the data needs cleaning before the move
Every quote is preceded by a free conversation.
When it is not worth it
If one person works with the database alone, rarely changes it and the data isn’t critical, Access is perfectly fine. Then it’s enough to back the file up regularly and document the macros once.
Common questions
- Is any data lost in the move?
No. The data is carried over in full and checked against the old database before the switch. While both run in parallel, Access stays in place. Before go-live, the data is migrated once more from the latest state of Access.
- Does everyone have to learn something new?
Hardly. The workflows stay the same, only the interface changes, and it stays close to the existing forms. If a process can be improved, say by replacing buttons with automation, that is discussed beforehand. The result is more comfortable than before in any case.
- Why switch at all?
Access, and Excel too, are not stable databases for mapping complex processes and important data permanently. The first corrupted file can wipe out the entire database and years of work without expert help.
More cases