Access web apps will be read only on April 1st, please plan accordingly

[Juan Soto]

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.

[#2 · Accepted solution]

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.

[#3]

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.

[#4]

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.

[#5]

Your tool cal AUTOMATE conversion of AWA pages to an equivalent accdb based form, then? 

So you take the html and automatically convert it into an Access form? That's pretty remarkable. Do you have a demo or sample one could see?

Thanks.

[#6]

Hi George,

PowerAccess and PowerGit provide fully automated conversion of the entire Access Web Databases (2010 Web Database format .accdb files) to Access Desktop Databases (.accdb files), complete with all objects, including Forms, Reports, Tables, Macros, and Data Macros.

We had successfully converted a massive Northwind Access Web Database sample, using PowerAccess and PowerGit, to a fully-functional, full-featured Access Desktop Database (supporting VBA, Design View, etc. unlike AWAs) without issue, within seconds, complete with all forms, reports, macros, tables (with structure and data converted from SharePoint Lists to local, Access DB-embedded tables) for example.

[#7]

If interested in trying it out PowerAccess, PowerSQL or PowerGit for Microsoft Access as soon as possible, you can subscribe at:

www.PowerAccess.net

Then we will send out a notification once we make available for Early Access Program (EAP) users as well as later public release. You can find more info about PowerAccess, PowerSQL and PowerGit there as well. We will be releasing some videos, as well as screenshots of our new add-ins and more info about PowerGit later on as well.

I look forward to getting feedback from you and others as soon as possible on what other new tools, automation features, and ways of avoiding boilerplate VBA coding you'd like to see next in PowerAccess and PowerGit 😃

[#8]

Given the fact that AWA's do not even support reports, I find that a bit of a broad claim, but let that be for the moment.

So, your tool takes the html and JavaScript which generate browser pages from the tables where they are stored in SQL Azure and uses that to generate an equivalent Access object. COngratulations on that achievement. 

[#9]

PowerAccess | PowerGit convert Web Database .accdb files to Desktop Database .accdb files, enabling use of full Access features and preparing for RDP or other deployment.

I can provide you with zip of the database before and after conversion.

If you are interested in checking that out, just email me at Dan@PowerAccess.net.

[#10]

Wait a second. 

"PowerAccess | PowerGit convert Web Database .accdb files to Desktop Database .accdb "

Perhaps you mistyped there. An Access Web App is not in an accdb file. So perhaps you meant to type accdw? Or perhaps you're talking about something else?

[#11]

Perhaps we should pursue your claims in a different venue or at a different time? 

Now I am wondering if, perhaps instead of Access Web Apps, what you are offering to convert would actually be the older, Access Web Database format, which was based on the older, SharePoint lists, running from a SharePoint site? 

That, of course, is not particularly unusual. There is a native functionality within that format to convert them to a desktop accdb.

The claim that you are able to convert Access Web Apps, including forms, and including reports--which don't even exist in Access Web Apps--is what piqued my curiosity. Indeed it would be quite an accomplishment to do the latter.

However, pending clarification of what your tool does, I guess it's best to let it go for now.

Thanks anyway.

George Hepworth

Co-Author Professional Access 2013 Programming (2013 Access Web Apps)

Co-Author Microsoft Access In a SharePoint World (2010 Access Web Databases)

[#12]

Hi George,

Yes, I was referring to conversion of Access Web Databases (2010 format .accdb files), not 2013 format Access Web Apps. I was just editing my previous posts to clarify that before responding here.  Thanks for pointing that out.

Access doesn't natively support fully automated conversion of all objects from Access Web to Desktop databases, which is where this automated feature comes it.  For Access Web Apps, I had touched on PowerApps as one alternative since there is still work required to convert to Access Databases.

The conversion feature is one of a few hundred features and functions provided by PowerAccess and PowerGit, but I thought relevant to point out, considering the deprecation of both Access Web Databases and Access Web Apps.

[#13]

Out-of-box Access fails to import most objects from Access Web Databases to Access Desktop Databases.

You can compare the results of manual, partial importing of each object vs. use of PowerAccess | PowerGit for complete, automate conversion in the attached zip.

The attached zip file (PowerAccess Automated Web to Desktop Database Conversion Demo Results.zip) includes:

1. Web Database .accdb file
2. Partially Import Result (using tools built-in to Access) .accdb file
3. Complete Automated Conversion result (using PowerAccess | PowerGit) .accdb file
4. PowerAccess Conversion Results Readme.txt" readme file

As detailed in the Readme file, manual conversion using built-in Access import tools only results in the following objects being imported, with all objects for Web Database use, except for Tables, failing to import:

Results of (Partial) Manual Import of Objects from Access Web Database to Access Desktop Database:

• 0 / 18 Queries
• 0 / 53 Web Forms
• 4 / 4 Desktop Forms
• 14 / 14 Tables
• 0 / 6 Web Reports
• 6 / 6 Desktop Reports
• 1 / 1 Desktop Macros
• 0 / 6 Web Macros

[#14]

So, thanks for clarifying that your tool is not intended to address the problem of expiring Access Web Apps, but for the previous version of Access Web databases. It would have been interesting, indeed, to do something with AWAs, but as we both know, that's not going to happen. The only thing possible there is to rescue the data itself; none of the interface objects.

This particular article in which we are participating, of course, refers to the end of support for Access Web Apps. Coincidentally, that does mean the old Access 2010 version Web Databases will also stop working at the same time, but it's hard to imagine there were still very many of them in use at this point anyway, fortunately.

In any event, thanks again for clarifying what your tool can, and can't, do.

Best of luck.