Microsoft Access application modernisation
For systems that have outgrown Access: a staged move to SQL Server, .NET or web technologies that keeps the business running and keeps the knowledge built into the system.
Replacement is one option, not the default
Access can remain an effective business platform when it is appropriately designed and supported. Applications often need attention as a business grows, and sometimes that attention is all they need.
Some systems do reach the point where Access is no longer the right home for them. When that happens the question is how to move without putting the business at risk.
Common reasons to modernise
- More users, or users in more locations, than a desktop database suits
- A need for web or remote access
- Integration with other business systems
- Security or audit requirements the current design cannot meet
- Dependence on components that are no longer supported
- A system that has become too costly or risky to change
A staged route, with sensible places to stop
Each stage delivers a working system and a benefit of its own. You can stop at whichever stage is appropriate. Nothing here implies that every organisation needs the final one.
- STAGE 01
Access
The existing application, understood, stabilised and properly supported. For many systems this is enough.
- STAGE 02
Access + SQL Server
The familiar Access front end stays. The data moves to SQL Server for multi-user reliability, security and scale.
- STAGE 03
Modern .NET / web application
Where the business case supports it, the front end is rebuilt in stages on the SQL Server foundation.
Preserving what the system knows
A mature Access application contains a great deal of business logic and operational knowledge: validation rules, pricing exceptions, approval steps, the report that finance relies on at month end. Much of it was never written down anywhere else.
A rewrite that starts from a blank page tends to lose this, and the gaps are found by users after go-live. Talyon's approach is to read the existing application first, record what it actually does, and carry that forward deliberately while improving the technology underneath.
Modernisation doesn't have to mean throwing away twenty years of business knowledge.
Target technologies
How staged migration works
The old and new parts of the system run side by side against the same SQL Server data while the work proceeds, so there is no single high-risk switch-over.
In-house tools and techniques, developed over many years of Access and .NET work, speed up the conversion and keep it consistent from one part of the application to the next. An experienced developer reviews and finishes everything they produce.
- Understand the existing systemAnalyse the data, the VBA and the workflows, and document the rules the business depends on.
- Move the data to SQL ServerEstablish a sound database foundation while the Access front end continues in use.
- Rebuild in sectionsReplace one functional area at a time in the new technology, in an order set by business priority.
- Verify against the originalCheck each new section produces the same results as the Access version before users move across.
- Retire Access when nothing depends on itOr keep it for the parts where it still does the job well.
Not sure whether to repair, upgrade or replace your Access system?
Start with an Access Health Check. You get a practical, written assessment of the system you have, the risks it carries and the sensible options, before committing to any larger project.