Host an Access split database backend online

Jon Bullock 40 Reputation points
2026-10-22T15:37:52.54+00:00

I code in VB and use a split Access db with the backend on the office server and the frontend on the various office workstations. Is it possible to place the Access db backend on an online server and have a version of the access frontends on mobile devices?

Microsoft 365 and Office | Access | Development
0 comments
Answer accepted by question author
DBG 11,801 Reputation points Volunteer Moderator
2026-10-22T15:52:05.17+00:00

Unfortunately, Access wasn't created to work well in a cloud environment. To do that, you will have to use a different approach. There are several options to move your data and application to the cloud, but relying on Access only won't be an easy task. I suggest you consider migrating your data to a cloud service or online database to give yourself several ways to access them. Good luck!

Was this answer helpful?

1 person found this answer helpful.
0 comments
Answer accepted by question author
Senthil kumar 2,995 Reputation points
2026-10-22T15:50:30.3533333+00:00

Hi @Jon Bullock

Why the direct approach fails

An Access backend (.accdb/.mdb) isn’t a database server. It’s a file that each frontend opens directly over a Windows file share (SMB). That works on a fast, stable office LAN. Over the internet, even through a VPN, it is slow, and a single dropped connection mid-write can corrupt the backend. Microsoft and the Access community strongly advise against it.

Access doesn’t run on mobile. There is no Access app for iOS or Android. Microsoft retired the browser-based Access Web Apps (via SharePoint) in 2018, so your VBA forms and code can’t run on a phone.

What works

1. Move the backend to SQL Server or Azure SQL. This is the key step and the least disruptive. You upsize the tables and relink your existing Access frontends to them through ODBC. Your forms, reports and most of your VBA keep working, with some tuning: queries that pull whole tables should filter on the server side, and pass-through queries and views help. Azure SQL, or SQL Server on a hosted VM, is reachable securely from anywhere. That solves the online part, and the office workstations carry on as before.

2. Build a separate mobile frontend on that same database. Access can’t be the mobile layer, so pick one of these:

  • Power Apps. This is the low-code option, and it connects natively to Azure SQL or Dataverse. It’s good for focused mobile tasks like data entry, lookups, approvals and photo capture. It’s licensed per user, so check the cost.
  • A web app. Given your .NET background, ASP.NET Core or Blazor is very doable, and you’d have full control. A responsive web app works on any phone browser with no app store involved.
  • Dataverse instead of SQL. Access has a Dataverse connector, so Access desktop and Power Apps can share the same tables. It’s a natural fit if the company is already on Microsoft 365.

3. Remote Desktop as a quick stopgap. Host the Access frontend on a terminal server or Azure Virtual Desktop and connect from tablets with the Remote Desktop app. You get the full app with no rewrite, but it’s awkward on a small phone screen. It’s fine for occasional use, not daily mobile work.

Typical roadmap

  1. Upsize the backend to Azure SQL or SQL Server and relink the existing frontends.
  2. Identify the few tasks people actually need on mobile. It’s rarely the whole app.
  3. Build just those screens in Power Apps or as a small web app against the same database.

Thanks.

Was this answer helpful?

1 person found this answer helpful.
0 comments

2 additional answers

Sort by: Oldest
Most helpful Newest Oldest

  1. AI answer

    2026-10-22T15:38:51.89+00:00

    Do not place the Access .accdb back-end on an Internet-facing file share; migrate its tables to Azure SQL or Dataverse, or host the complete Windows Access application through Remote Desktop Services or Azure Virtual Desktop.

    Microsoft specifically warns against running a split Access database over a WAN, VPN, or Azure Files because performance can be slow and the database can become corrupt. Supported alternatives include SQL Server/Azure SQL, Dataverse, SharePoint lists, and Remote Desktop Services (RDS). ^1^

    Option 1: Keep the Access front-end and move the data to Azure SQL

    This is the closest replacement for your current configuration and generally requires the least front-end redesign.

    1. Create an Azure SQL Database.
    2. Back up the existing Access front-end and back-end.
    3. Install and open SQL Server Migration Assistant (SSMA) for Access.
    4. Select File → Migration Wizard.
    5. Add the Access back-end database.
    6. Connect SSMA to Azure SQL.
    7. Convert the schema, load it into Azure SQL, and migrate the data.
    8. On the wizard’s Link Tables page, select Link tables.
    9. Test every form, query, report, and VBA data-update routine before deployment.

    SSMA supports migration from Access to Azure SQL Database and can replace the Access tables with linked Azure SQL tables, allowing the existing forms, reports, and queries to continue using server-hosted data. ^2^ ^3^

    After migration:

    • Keep one local copy of the front-end on each Windows computer.
    • Give Azure SQL tables suitable primary keys or unique indexes.
    • Move expensive queries to SQL views, stored procedures, or Access pass-through queries if linked-table performance is poor.
    • Review VBA recordset code. SQL Server/Azure SQL record additions can require dbSeeChanges:
    Dim db As DAO.Database
Dim rs As DAO.Recordset

Set db = CurrentDb
Set rs = db.OpenRecordset( _
    "dbo_Customers", _
    dbOpenDynaset, _
    dbSeeChanges)

rs.AddNew
rs!CustomerName = "Example customer"
rs.Update

    Microsoft documents dbSeeChanges, identity-column handling, query performance considerations, and other post-migration differences. If SQL authentication is used, SSMA warns that its password is stored in clear text in linked Access tables; use an appropriate secure authentication design instead. ^4^

    This retains the Access user interface only on Windows: Access itself is a Windows database application, not an iOS or Android application. ^5^

    Option 2: Use the existing Access front-end from mobile devices

    Host Access and its front-end on Windows session hosts using Azure Virtual Desktop or RDS. Users then operate the Windows application remotely from their phones or tablets; the Access front-end is not installed on the mobile device.

    Keep the front-end and back-end—or Access and Azure SQL connectivity—close together in the hosted environment. Publish either the full desktop or the Access application, then assign users. Azure Virtual Desktop clients can connect from Windows, macOS, iOS/iPadOS, Android/Chrome OS, and web browsers. ^6^

    This route preserves your VBA application, but forms designed for a mouse and desktop display may need larger controls and simplified navigation for practical mobile use.

    Option 3: Create a true mobile front-end

    For a touch-oriented mobile application, migrate the Access data to Dataverse and rebuild the required forms and workflows in Power Apps.

    1. In Access, use its export/migration feature to migrate supported tables and relationships to Dataverse.
    2. Check data types and features before migration because not every Access data type maps directly.
    3. Build a canvas or model-driven Power App over the migrated tables.
    4. Share the app and assign the necessary Dataverse security roles.
    5. Users open it through Power Apps on iOS or Android.

    After migration, the existing desktop Access client can continue managing the data while Power Apps supplies desktop, phone, and tablet interfaces. ^7^ Power Apps supports canvas and model-driven apps through its mobile player, including mobile optimization and offline capabilities. ^8^

    In short:

    • Preserve the Windows Access UI: Azure SQL plus linked tables.
    • Preserve the entire application on mobile: Azure Virtual Desktop or RDS.
    • Provide a native-style mobile UI: Dataverse plus Power Apps.
    • Avoid: exposing or synchronizing the Access back-end file through an Internet, WAN, VPN, or Azure file share.

    References

    1. Deploy an Access application | Microsoft Support
    2. SQL Server Migration Assistant for Access (AccessToSQL)
    3. Migration Wizard (AccessToSQL)
    4. Link Access applications to SQL Server and Azure SQL (AccessToSQL)
    5. Office applications details
    6. Prerequisites for Azure Virtual Desktop
    7. Migrate Microsoft Access data to Microsoft Dataverse
    8. Use Power Apps on mobile devices
    AI-generated content may be incorrect. Read our transparency notes for more information.

    Was this answer helpful?

  2. Deleted

    This answer has been deleted due to a violation of our Code of Conduct. The answer was manually reported or identified through automated detection before action was taken. Please refer to our Code of Conduct for more information.

    Comments have been turned off. Learn more

Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.