By default, Access operates without a database server. Each user runs a separate copy of the program, which directly accesses the data file. When a database server is introduced, the users’ machines stop doing the hard work – they simply query the server, which returns the results.
Expertise
Database Upsizing - Performance and Scalability
As businesses grow, their databases can become too large for Access to handle efficiently. Blueberry can help by upsizing your Access database to a server-based system. Blueberry's team of experts can assess your current database, recommend the best course of action, and help you migrate your data with minimal disruption.
Database Upsizing
How Upsizing Works
The Basics
Databases generally comprise two parts: the front end, which users interact with (forms, reports, and queries), and the hidden back end, where data is stored. In Microsoft Access, the default file format .MDB was replaced by .ACCDB starting with Access 2007, providing enhanced features and improved compatibility with modern Office and cloud services.
Upgrading or modernising an existing database can involve updating either or both of these components. Today, this often means migrating data to a cloud-native database or microservices-based architecture rather than simply moving to a traditional database server. The front end may be retained if it meets requirements, or rebuilt using modern technologies such as C#, JavaScript frameworks (React, Angular, Vue), or Python, instead of classic Visual Basic (VB6), which is long obsolete.
While web-based applications were once seen as an optional upgrade path, cloud-native applications, single-page apps (SPAs), and progressive web apps (PWAs) are now the default approach for new systems, offering scalability, cross-platform support, and improved maintainability compared to legacy desktop forms.
Upsizing in Brief
The first choice is to decide if the front-end (forms and reports) are still usable.
- If the forms are OK, then only the data need be moved.
- Moving the data is relatively easy, but the migration isn’t finished until a programmer has completed a compatibility check on tables, queries and code.
- Migrating the forms and reports to a new system is quite a lot more complex.
Data-Only Upsizing
Many companies historically had Microsoft Access databases with front-end forms that worked well but suffered from limited reliability or performance. The traditional solution was to move the data only to a server while leaving the Access forms intact. Access supported this through ‘linked tables’, where each table was copied to a database server, and the local table was replaced with a link to the new table.
This linked-table approach is now considered a legacy workaround rather than a best practice. Modern enterprises increasingly favour full migrations to cloud-native databases or web-based applications, rather than maintaining hybrid Access-SQL setups. While on-premise SQL Server or Oracle installations are still in use, cloud databases like Azure SQL, AWS RDS, Google Cloud SQL, PostgreSQL, and Amazon Aurora are increasingly the default for new deployments.
Legacy concerns, such as differences between Access SQL and SQL Server SQL, are now largely mitigated by migration tools like SQL Server Migration Assistant (SSMA), which handle most conversions automatically. Visual Basic for Applications (VBA) remains supported but is considered a legacy technology, and modern solutions typically replace it with C#, JavaScript (React, Angular, Vue), Python, or low-code/no-code platforms.
Today, businesses looking to modernise legacy Access systems often choose from:
- Cloud databases – Azure SQL, PostgreSQL, Amazon Aurora
- Low-code platforms – Power Apps, Retool
- Full-stack web apps – React + Node.js + SQL backends
- No-code solutions – Airtable, Notion databases
While the classic Access upsizing approach is still technically possible, most organisations now see it as outdated. Full migrations or modern low-code/cloud-native architectures offer better scalability, maintainability, and long-term reliability.
Front End Upsizing
Front-end upsizing rarely solves performance issues, as forms and reports are generally not the bottleneck. Instead, it is usually undertaken for two main reasons: to move to a more capable programming environment as system complexity grows, and to allow access via the internet or intranet, which has become essential with widespread remote working.
The Access programming environment, while suitable for small projects, is now considered unsuitable for larger or modern applications. Its built-in VBA language is limited and inflexible, and classic Visual Basic (VB6) is long deprecated. Delphi (Pascal-based) still exists but is niche in 2025, with very few new projects adopting it.
Modern alternatives for front-end development focus on mature, scalable, and flexible technologies. C#, now over 20 years old, is widely used in enterprise applications, particularly with .NET 6/7/8 and .NET MAUI/Blazor. Legacy frameworks like ASP.NET WebForms are obsolete. For web-based applications, popular front-end frameworks include React, Angular, Vue.js, Svelte, and Blazor for full-stack C# development.
Moving to these modern platforms allows companies to deliver interactive graphics, responsive user interfaces, and seamless integration with other systems. Web-based approaches also make applications accessible from any device with a browser, reducing deployment complexity while supporting remote and hybrid work scenarios. This option is discussed in Publishing a Database on The Web.
See Also:
We're easy to talk to - tell us what you need.
CONTACT USDon't worry if you don't know about the technical stuff, we will happily discuss your ideas and advise you.