Convert Microsoft Access to a Web Application: Your Options

TL;DR

• Separate remote access, a database migration and a new web application. Each changes a different part of the system.
• Moving tables to SQL Server can preserve the Access front end. It does not automatically create browser forms or replace VBA.
• Power Apps with Dataverse is an option to evaluate, not a one-click conversion. Check data types, business rules and production licensing.
• Include reports, attachments, imports and actions hidden behind form buttons in the replacement scope.
• Test one complete workflow with existing records and ordinary users. Where Access remains, verify that it follows the same rules as the new interface.

What needs to change: where people work, or how they work?

For example, suppose an equipment-service company uses Access to register jobs, record parts and print service sheets. Office staff can complete the work, but engineers now need to update jobs from other locations. The owner asks for the database to be put online.

That request leaves an important choice open. Do engineers need the existing Windows application remotely, or a simpler browser workflow for finding a job, adding a photo and submitting the result? A remote session could satisfy the first requirement while being a poor fit for the second. This company is a hypothetical example, not a Caemcore client case.

Identify the starting point too. The Access file might contain the business data, or it might be an interface to a database already running elsewhere. Record the actual table locations before asking anyone to migrate them. Replacing the interface does not automatically require replacing a working SQL database.

Compare five routes before commissioning a conversion

Use the table to shortlist an approach, then test it against a job your staff actually perform. The Microsoft-supported database and remote-delivery routes are explained below. The selection criteria are editorial guidance, not a claim that every Access application fits a particular route.

Keep the ready-made option in the comparison. Give its supplier the same job, exception and report to demonstrate. Our custom versus off-the-shelf guide covers that broader decision. An Access application worth replacing does not necessarily need a custom replica.

What does moving Access to SQL Server actually change?

It can change the data store while leaving staff in Access. Microsoft describes sharing an Access application through a database server, with the desktop application linked to the server's tables.

Microsoft's SQL Server migration guide is explicit about the boundary: SQL Server Migration Assistant, or SSMA, mainly converts tables and select queries without parameters. It does not convert forms, reports, macros or Visual Basic for Applications (VBA) modules. A quote for that migration is not a quote for a working web replacement.

Consider this route when the existing screens suit the work and the database change addresses a verified requirement. Test the retained queries and forms with representative data and the actual connection. Do not approve a server move solely on a promise that every screen will become faster.

If your tables are already in SQL Server, ask a different question: which screens and business rules need a new interface? Keeping that backend may avoid a second data move. It still requires checking what the old Access application does before and after each database write.

Would remote Access solve the immediate problem?

Remote delivery is worth evaluating when staff simply need their existing application away from the office. Microsoft's Remote Desktop Services web client provides browser access to Windows applications published by an administrator. It delivers a remote application session rather than converting Access forms into web pages.

Check the exact devices, printing and file-transfer needs before choosing it. The documented RDS web client does not support mobile devices; that limitation applies to this particular client, not every remote-access product. An engineer expecting to upload photos from a phone needs a different, demonstrated arrangement.

Ask the IT provider to include the hosting, access management, applicable licensing and support responsibilities. Remote delivery may be a useful bridge or a sufficient long-term answer. Judge it by whether people can complete the job, not by whether the login page opens in a browser.

Can Power Apps replace the Access interface?

Yes, when the proposed Power Apps solution can support the required work. Microsoft documents migrating Access data to Dataverse, its data platform, while continuing to use Access and building Power Apps against the same data. Treat that as a way to build a new application around shared records, not an automatic conversion of the existing desktop screens.

Start a trial with a representative form, its calculations and its output. Do not test only a simple contact list when the business depends on job approvals, related parts and service documents.

Check the migration details before accepting the sample. Microsoft's data-type guidance says calculated fields transfer their last calculated value, not their calculation logic. Its documented attachment migration supports a single attachment per column. Unsupported data can also be left in Access while supported tables move.

For the service-company example, yesterday's correct job total could therefore appear in a migrated record while the rule needed to calculate tomorrow's total is missing. Change the inputs in the proposed application and check the new result. For a job with several photos, account for every file and its relationship to the job rather than accepting the first visible thumbnail.

Include the actual licensing arrangement in the comparison. Microsoft's Power Platform licensing FAQ distinguishes limited Microsoft 365 rights from the rights required for full Dataverse use and premium connectors. Specify the intended users, connectors, storage and automation. An existing Microsoft 365 subscription alone is not a complete production-cost estimate.

What must a custom web application reproduce?

The scope should describe the work people need to complete, including the rules currently implemented inside Access. Preserve useful behavior; do not recreate every unused form simply because it exists.

Follow a button beyond the visible form

In the hypothetical service application, clicking Complete job might validate the parts used, save a completion date, produce a service sheet and prepare a customer email. Inspect the actual implementation to establish which of those actions exist and where they happen.

Have the developer record the form event or macro, the VBA it calls, the queries it runs and any external files or services it uses. Check startup actions, scheduled imports and tasks launched outside Access as well. A screen inventory will miss work that happens without anyone opening a form.

Decide which behavior must remain and which should change. For example, an operator's ability to correct a completed job may need an explicit approval step. Record that as a new requirement rather than silently changing it during the migration.

Treat reports and desktop dependencies as deliverables

Keep samples of the documents people rely on: a service sheet, a batch report, an export for another system. Specify their fields, calculations, grouping and required layout. A dashboard showing similar totals is not a replacement for a document the receiving team cannot use.

Inspect dependencies such as shared-folder paths, Outlook automation, printer selection and barcode equipment where they exist. Ask how each will work from the destination environment. A demonstration on the developer's laptop should not rely on a local program or file that staff will not have.

Put rules where every permitted entry point obeys them

A browser form should not be the only place that checks who can approve a job. OWASP's authorization guidance requires permission checks on every request and enforcement outside client-side controls. Specify access to job records, attachments and exports as well as visible buttons.

If the old Access client remains connected to the same database, test it too. A new web rule does not constrain an older client that still writes directly through a different path. The design must enforce the shared requirement across those paths, or remove the old client's permission to perform the affected action.

Assess the data before pricing the full migration

For the SQL route, Microsoft's Access-to-Azure-SQL migration guide describes an SSMA assessment report with conversion statistics, errors and warnings. Ask to see the relevant findings and the proposed resolution for each blocker. Database-conversion results do not measure the work to rebuild reports or form logic.

Have the developer inspect keys, table relationships, lookup values, attachments and fields with special behavior. Preserve the connection between each historical job, customer and part. A familiar label in a dropdown is not enough: confirm which identifier is stored underneath it and what it references after migration.

Attachment handling deserves a separate estimate. Microsoft's SQL Server migration guide identifies tables with attachments as an SSMA limitation. Define how files will be extracted, stored and linked in the replacement; perform that preparation on a controlled copy. Do not remove production attachments merely to make a migration tool accept a table.

Retain historical values when the business needs them. An old service job should not acquire today's part prices just because the replacement now calculates totals differently. Separate preserved transaction values from rules that apply to new work.

For source files and imports around Access, our guide to moving workflows out of spreadsheets explains mapping and reconciliation in more detail. Apply the same record-by-record checks to the selected migration scope rather than treating a successful import message as acceptance.

Request this trial before approving the whole replacement

Use a non-production environment, synthetic accounts and representative test records. Prevent the trial from sending real customer emails or changing live integrations. In the service-company example, select an existing job with related parts, an attachment and a completed service sheet.

1. Recover the complete job. Find it using its original reference. Verify its customer, parts, status, historical amounts and files. Compare the required service-sheet output with the approved sample, including a multi-page example where the layout matters.
2. Exercise a rule, not just a saved value. Create a new test job and change a quantity or other input used in its calculation. Check the recalculated result, required-field validation and completion action. Also try the correction or cancellation staff need after an ordinary save.
3. Use two people on the same record. Have one operator save a change while another has an older version open. The second save should follow the agreed conflict-handling rule, rather than silently discarding the first person's work. Test any retained Access client in the same scenario.
4. Check restricted work through every active interface. A normal engineer must not gain approval rights by bypassing the visible button. Test the job, file and export boundaries with the wrong account. Where Access is retained, confirm its permitted writes cannot bypass the new restrictions.
5. Complete the handoff and recovery. Produce the required report or downstream export, then simulate a failed release after a new job has been entered. Demonstrate where that new job survives and who authorizes the next step. If two data stores are used during transition, include a later correction and deletion in the catch-up test.

These are proposed acceptance checks, not results from a tested Access migration or a complete security assessment. Record passes, failures and untested dependencies separately. A route that fails an essential condition needs a revised design and estimate before it becomes comparable with one that passes.

What should an Access-to-web proposal include?

Ask for separate descriptions of the database work, replacement workflows, reports, integrations and rollout. Name the Access functions that remain, who can still use them and how long they are expected to stay. A retained reporting client can be intentional; an undocumented second place to edit live jobs is a different commitment.

Agree which history must be in the new application and how the rest remains accessible. Include training and the administration tools staff will need after losing Access's editing interface. Record who owns the hosting accounts, source code, release instructions and ongoing support.

Compare the same release, not a table-migration fee against delivery of a complete application. Include recurring platform licences, hosting, support and any period when both systems must operate. Do not use file size or form count alone to infer a price or deadline. A small database can contain substantial business logic and document-generation work.

For the live switch, specify where new entries, corrections and deletions belong at each stage. Rehearse the final transfer or shared-database release and define a stopping point before staff depend on it. Recovery must preserve work entered after the switch, not merely restore an earlier application file.

Choose the smallest route that satisfies the actual requirement. If a remote session lets the team complete the existing job, a web rebuild may be unnecessary. If the requirement is a new browser workflow, require evidence for that workflow, its rules and its data before commissioning the rest.

About Caemcore

Caemcore builds custom software for companies that outgrew off-the-shelf tools.

Internal systems, integrations, web and mobile apps, and products built from scratch. Small senior team, Warsaw-based, working with clients across the EU, US and UK.

You get a price range and a timeline before development starts, a working demo every Thursday, and a final invoice that matches the number quoted on day one.

Not sure what you need? A 30-minute call, free: what the task actually is, whether it needs building or an off-the-shelf tool covers it, a range and a timeline. You get that whether we work together or not.

FAQ

Can we keep Access reports after replacing the data-entry screens?

Yes, when the retained reports can read the intended data through a supported connection. Specify whether Access is read-only for this purpose and who maintains the report definitions. Reconcile the output against the new application and keep any required reference data available. Retaining a reporting client should be an explicit part of the design, not an unnoticed dependency that appears at month-end.

Does putting an Access file in SharePoint or OneDrive turn it into a web application?

No. Storing the file there does not convert its forms or VBA into a browser interface. Microsoft also recommends avoiding opening an Access database directly from those locations because local downloads and later uploads can produce multiple copies and unexpected behavior. File sharing, linking to a data source and delivering a web application are different arrangements.

What if we only have an ACCDE file?

Look for the original editable ACCDB file and the current backend before accepting a migration estimate. Microsoft documents that saving as ACCDE removes editable VBA source and prevents design changes to forms, reports and modules. A working ACCDE can help demonstrate behavior, but it is not equivalent to the original source. Ask the supplier to identify what can be inspected and which rules need to be reconstructed and confirmed.

Will a replacement work when staff have no internet connection?

Make offline work a separate requirement rather than assuming it follows from moving to the web. Specify which records must be available, which changes can be made offline and how conflicts are resolved when the connection returns. Test the proposed device and client in that state. A read-only cached screen is not the same as an offline job-completion workflow.

Can we remove unused Access forms and reports instead of rebuilding them?

Yes, after checking their dependencies and agreeing the scope with the people responsible for the work. Ask about infrequent tasks such as year-end reports, bulk corrections and customer disputes, not only daily activity. Keep a usable archive where required. Mark each omitted function and its replacement process so a lower quote does not conceal work the business still needs.

Sources

• Microsoft Support, Migrate an Access database to SQL Server. Checked 16 September 2026.
• Microsoft Support, Ways to share an Access desktop database. Checked 16 September 2026.
• Microsoft Learn, Get started with the web client for Remote Desktop Services. Checked 16 September 2026.
• Microsoft Learn, Migrate Microsoft Access data to Microsoft Dataverse. Checked 16 September 2026.
• Microsoft Learn, Data types and sizes for Access data migration to Dataverse. Checked 16 September 2026.
• Microsoft Learn, Power Platform licensing FAQs. Checked 16 September 2026.
• Microsoft Learn, Access to Azure SQL Database migration guide. Checked 16 September 2026.
• OWASP, Authorization Cheat Sheet. Checked 16 September 2026.
• Microsoft Support, Hide VBA code from users. Checked 16 September 2026.

Microsoft product capabilities and migration limitations were checked on 16 September 2026 against its documentation. The comparison criteria, equipment-service scenario and acceptance trial are editorial planning guidance, not a Caemcore Access case study or measured migration results. No application, conversion vendor or licensing arrangement was tested for a particular customer.