I ran across a throwback photo from my Facebook memories from Access Day Denver in October 2014. On the screen behind the presenter was the title "Lifecycle of an Access 2013 Web App." That moment captured Microsoft's big promise to bring Access into the cloud era by letting you take your database to the web. The presenter was Kevin Bell, an Access Team test engineer at the time, and the event was led by Armen Stein from J Street Technology. Armen has been an Access MVP since 2006 and still runs Access Day events. The last one I attended was last year in Redmond after the MVP Summit, and I believe he is doing another one again this year. They're awesome. Attend if you can.
With Access 2013, Microsoft promised to give developers a simple way to publish their databases online. The new Access Web App feature let you design tables, forms, filters, and views inside Access and then publish them to SharePoint. Once online, users could open the app in their web browser without needing the full Access client installed. Behind the scenes, the data lived in SQL Server, and all of the business logic was handled through macros instead of VBA. Forms were rendered as web pages through SharePoint and Access Services. It sounded great in theory: the power and speed of Access development, combined with the reach of the web, without having to learn HTML, JavaScript, or ASP. Microsoft said this was the future of Access, the next step in its evolution.
In practice, though, the concept had major limitations. You couldn't use VBA or any of the traditional Access form events that developers relied on. Everything had to be done with macros, which were harder to debug and much less flexible. Reporting was another major problem. If you wanted formatted reports or printable output, you had to export data to Excel or link the SQL tables back to a traditional desktop Access file. The web app itself had no reporting tools at all. The user interface was also restrictive. You were limited to whatever Access Services would render through the browser, which meant no custom controls, no dynamic layouts, and no advanced scripting. Even the performance was disappointing because every click had to travel through the server, which made the apps sluggish under real-world conditions.
Another problem was that the entire system depended on SharePoint with Access Services enabled. You either had to run SharePoint on-premises or use an older Office plan that still supported it. When Microsoft eventually shut down Access Services in Office, that effectively ended Access Web Apps. Even before that, most developers had already lost interest. Losing VBA, form control, and flexibility made the web apps feel like a downgrade rather than an upgrade, and very few organizations adopted them.
By 2017, Microsoft had quietly shifted its attention elsewhere. Access Web Apps stopped receiving updates, and the company began promoting PowerApps, Flow, and the broader Power Platform as the new way to build cloud-based business apps. By 2020, Access Services was completely shut down in Office 365. Technically, on-prem SharePoint servers can still host Access Web Apps today, but even Microsoft discourages that approach. The product is dead. (1)
That said, some value remains. If you still have an old Access Web App, the data backend is SQL Server, which means you can link them back into a normal Access front end. Doing that restores all the power of VBA, forms, and reports that made Access great in the first place. In other words, the web app itself might be gone, but the data does not have to be.
When I put out feelers and ask people what new feature they most want to see in Access, the number one answer is almost always the same: they want to put their Access apps on the web. They want to build their database just like they always have, complete with forms, reports, and VBA logic, but then click a button and publish it to the web. Getting your tables into SQL Server is easy enough, and I even have a seminar that teaches you how to do that. The hard part is the front end. Access is the ultimate rapid-development environment for forms and user interfaces, and nothing else has really replaced it.
If someone could create a tool that preserves that same Access experience but makes it truly web-based, that would be a killer app. What do you think?
(1) And if I had a nickel every time I got an email or saw a post online from people who think that Microsoft killing Web Apps meant that they were killing Access, I could buy myself a really expensive steak dinner.
In Visual Studio, you can use VB.Net to create either a desktop app or a web app. So you can conceivably re-use lots of VB code when you convert a desktop app to a web app. But there would still be substantial re-coding to be done due to the many differences in user interface, object models, event-handling, the overall flow of operations, additional coding environments (HTML, CSS, etc.), etc., between desktop and web environments. The re-coding may be substantial enough to make it a consultant-level job in most cases.
One way to avoid having to convert is to create a web interface that can be used locally and on the web. When everything is done on web interface, there is nothing to convert. The downside is not being able to use desktop-style user interface, which some users prefer. But if you have a business to run, giving up some style points may be a small price to pay for not having to do potentially expensive web conversion in the future.
Kevin Yip
@Reply 13 months ago
Below are my calculator apps, done for Windows desktop and for web. Other than manually designing the UI for each, I didn't have to do much re-coding, as most of the code was copied and pasted from one to the other. This is how a language can be "portable." Almost all the popular languages like javascript, C++, python, etc., are portable. VBA, sadly, is not, and can only be used in Office apps. Portability is usually how multi-platform development is done, not the type of magical conversion Access web app tried to be. When I first heard of Access web app, I immediately felt it was too good to be true. Maybe AI could do it in the future.
Kevin Yip
@Reply 13 months ago
Kevin Yip
@Reply 13 months ago
Sorry, only students may add comments.
Click here for more
information on how you can set up an account.
If you are a Visitor, go ahead and post your reply as a
new comment, and we'll move it here for you
once it's approved. Be sure to use the same name and email address.
This thread is now CLOSED. If you wish to comment, start a NEW discussion in
Captain's Log.