Forum Discussion
Access web apps will be read only on April 1st, please plan accordingly
A year ago Microsoft announced that Access Service in SharePoint will be discontinued. We hope you've had a chance to migrate your app, but if you haven't here are some of the platforms you can recreate your application into:
- PowerApps - Web App
- Microsoft Access - a "regular" Access file that is not a web app
- Another web technology such as php or .Net
- Other platforms
Which technology you pick will depend on:
- Your IT department's guidelines on applications, some may prefer .Net or don't have any preference
- Your budget to re-architect the solution, some platforms, such as PowerApps, are easy to develop but are not as powerful, others such as .net are more powerful but much more expensive to develop, with Access in between the two
- Your time constraints: Given the short period between now and April 1st, you may need to put together an Access application instead of .Net just because it's faster.
What you should absolutely not do is wait, the time to act is now if you do have a mission critical access web application.
I have written a series of blog posts on rescuing your data from its Soon-To-Be-Late AWA. If you haven't yet figured out how you're going to do that with your data, right now would be a very good time to get that taken care of.
- George_HepworthSilver Contributor
I have written a series of blog posts on rescuing your data from its Soon-To-Be-Late AWA. If you haven't yet figured out how you're going to do that with your data, right now would be a very good time to get that taken care of.
- George_HepworthSilver Contributor
This claim really intrigues me as I've never heard anyone from Microsoft talk about doing anything like it.
"There are ways of automating conversion from AWA to Desktop Database apps."Are you claiming that you have a tool to
- Migrate data from the SQL Azure database to Access local tables (trivial in fact)
As well as
- Create new forms in an accdb which duplicate or replicate the AWA pages in layout AND function
- Recreate or migrate all queries
- Migrate macros and data macros in the accdb
If you can do that, and end up with a fully functional accdb complete with forms, queries, macros and, of course, tables, it would be interesting indeed. Of course, I'm referring only to the claim to have an automated way of doing it.
Thanks for supplying details.
- DanMoorehead_PowerWeb5AIIron Contributor
Hi George,
Here is my previous post (which seems to have been deleted by moderators for some reason), which I have re-posted (together with edits for clarity) so that it's clear what you are responding to:
As George and Juan pointed out, it's critical to migrate away from Access Web Apps (AWA) and Access Web Databases now that they and Access Services for SharePoint have been deprecated by Microsoft. As Juan had mentioned, conversion to Access Desktop Databases (.accdb's) is one of the key methods for doing so, and can be combined with RDP/RemoteApp hosting for AWA-like web/cloud/mobile deployment. It's important to address this before the April 2, 2018 depreciation deadline when AWAs become read-only.
For those using earlier also Access Web Databases (Access 2010 format .accdb files for Web deployment), Access Web Database to Desktop Databases automated conversion may be the best option.
This is possible, for example, by using the new PowerAccess and PowerGit for Microsoft Access tools which, among other things, support automated conversion from Access Web Databases (2010 format Web Database .accdb) to full-featured Access Desktop Databases (.accdb).
PowerAccess, PowerSQL and PowerGit are new tools which modernize, automate and cloud-enable Microsoft Access through add-ins, framework and templates. One of the many new tools and features they provide is for fully automated conversion from Access Web Databases to full-featured Access Desktop Databases (.accdb files), including complete, automated conversion of all database objects (Forms, Reports, Tables, Queries, Macros, Data Macros, etc.).
You can then "cloud host" those desktop databases for streamed real-time use by hundreds of simultaneous users from mobile devices, PCs and web browsers - for use similar to your existing AWA or Access Web Database - as described further below.
One advantage that Access desktop databases provide is in enabling use of the full set of Microsoft Access development and automation tools (VBA, Design View, etc.). Though designed for multi-user use by hundreds of simultaneous users, they don't provide out-of-box provide support for web and mobile use, and are instead typically hosted on a file share (eg. via VPN).
That said, there are web & cloud deployment options for even Access Desktop Databases, such as Remote Desktop (RDP), especially with RemoteApp use (which streams just the window, not the desktop, and no need to launch the app, and scales up for many simultaneous users with the same host).
There are solutions for simplifying setup and cloud/streamed hosting of your Access databases like this. For example, PowerAccess has server setup tools and components which allow you host your Access desktop databases from any Windows PC (with or without Windows Server) to support hundreds of simultaneous users, and without requiring per-user licensing / CALs for various products.
There are also other options for RDP and RemoteApp deployment, as well as alternatives to Access Desktop Databases, such as completely redeveloping using PowerApps + Azure SQL or SQL Server, as both Juan and George had touched on.
Whatever approach you take, I agree with George that it's worth migrating away from Access Web Apps and Access Web Databases sooner rather than later, considering that these have now been deprecated and Access Services / Access Web Apps are going read-only on April 2, 2018.
Disclaimer:I had developed PowerAccess, PowerGit and PowerSQL as solutions to modernize and automate Microsoft Access with new database builder tools, framework, templates, and features.
Note to Moderators:
Please let me know if I need to make any further edits to this post (which I had previously rewritten to conform to described guidelines) instead of deleting again, if possible, as it specifically relates and provides answers to the thread topic (methods for converting/migrating away from Access Web Apps / Access Services for SharePoint before the deprecation deadline) and is being referenced in a discussion asking further details about it.