Updating the Access Services in SharePoint Roadmap

When we first created Access Services in SharePoint, we set out on a mission to enable both information workers and developers to quickly create data centric web applications with little or no programming. Over the last several years it has become clear that the needs of our customers have grown beyond the scope of what Access Services can offer, such as mobile device support, integration with line of business data, and professional developer extensions.


When we researched how to close these gaps, the answer became clear as well; we’re aligning efforts behind Microsoft PowerApps as the way to build no-code business solutions on desktop and mobile devices.  PowerApps offers a comprehensive set of application building tools, connection to custom web APIs, and a wide array of database options including SharePoint lists, SQL Azure databases, Common Data Service and third-party data sources.


We no longer recommend Access Services for new apps. This feature will be retired from Office 365. We will stop creation of new Access-based apps in SharePoint Online starting June 2017 and shut down any remaining apps by April 2018.


We know that many of you have come to depend on Access custom web apps and we are working to make the transition to PowerApps as smooth as possible. We have added a feature to   export your data to SharePoint lists where you can create PowerApps and Microsoft Flows. We have also published guidance on how to port your custom web app to PowerApps here.


We will include Access Services and Access Web Apps in the next version of SharePoint Server.   Access Web Apps and Access Services will continue to be supported in all current versions of on-premises SharePoint servers for the remainder of the product lifecycle.


Access Desktop databases (.ACCDB files) will not be impacted by this decision. If you’ve used previous versions of Access, these are the databases you’re already familiar with, and you’ll continue to work with files you’ve created in the past. Desktop databases have all the powerful features, such as VBA, that has made Access such a popular way to run a business. We will continue to invest in Access Desktop databases to expanded data connectivity, management, and developer features.


- the Access and SharePoint teams


Senior Member
Right, it is now 5 days since the announcement and I still don't understand: 1) Microsoft's reasoning in doing away with AWAs. Mind you, if they really think that AWAs can be replaced by PowerApps it means they don't know what AWAs can do (or PowerApps or both). 2) Why Microsoft are only giving us 13 months to get all AWAs out of Office 365. 3) Why Microsoft want to be thought of as a bunch of untrustworthy fools by developers and the poor, unfortunate companies who currently rely on this Microsoft technology for some of their stuff, including some big companies. Do you think someone from Google or Applie has infiltrated Microsoft?
Senior Member

Wolfgang, we can assist to deploy your own SP2016 and SQL-Server on Azure. Your apps will run better they would ever have on O365. We can also implement forms based authentication for you. That way you don't have to pay for each user but for the servers (just as you could invite non subscriptional users for AWA in O365). If you don't want all that, we can deploy it for you on SPLA-basis on our servers too. A couple of months ago, we were forced to deploy our own servers because Microsoft refused to address our issues but we lost some extreme annoyances along with that. Rob

Regular Visitor



what you are offering to Wolfgang is to move a SaaS to a IaaS. This will have a huge impact in cost for licensing and maintenance point of view.


I just wanted to point it out for Microsoft to understand that it is not a viable solution for many of the AWA users.


Occasional Contributor

And this post now is few days old, it feels as if we speak to each other, while Microsoft people are silent, after the shy interference of Chris that has made no sense, and in few days more, we will not be able to write here and will be boldly told: Comments are closed.

I have been always saying that business is about people. Please show some respect to your customers dear Microsoft. If you care about how to make more money, many care about feeding our children, and you are putting our work in risk for real. I would suggest you retire AWA, after 5 years, and necessarily after 2 years from making PowerApps REAL BUSINESS DATABASE SOLUATION. 




Regular Visitor
Occasional Contributor

Thanks Javier, that suggests that we should unify a legal position against the content of this post and act.

Regular Visitor

I s like selling a car and in a year you cant get tyres for it. Microsoft, sounds really unfair to me.


Please respond.

Regular Visitor
Regular Visitor

This even worse I am developing and Angular2 SharePoint Hosted App that communicate with O365 using Restful services. But I can't guarantee to the users that the app will work at least for 2 years because Microsoft can change something in the services or even get rid off the app model in shot notice.


Then you wonder why developers don't spend efforts to create app in the O365 app store.


I like more the Dynamics 365 model where you can stick with a version for 2 years before you are forced to change to the latest.



Senior Member
Javier, You pointed us to https://www.mcsmlab.com/blog/2015/9/1/update-to-office-365-lifecycle-support-policy-for-office-365 . So that means Microsoft may well have been abiding by the letter of their rules, even if not by the spirit of them. So it means that Microsoft could also pull PowerApps in 12 months as well if they wanted if people come to realise that it is little more than a toy at the moment and don't get to use it significantly.

Alan, the way I've read it (the clause under the one circled) they can cease ANY part of Office 365 with 12 months notice - if that's the case then how can anyone rely on it?


Of course in the normal real world companies try to deliver great customer service and not allienate them.

Regular Visitor
MSFT looked never that arrogant to me. I started with Office 1.0 way back then and have enjoyed the various revisions the Office suite has gone through. As a small business owner in Shanghai I moved all back office systems to Office 365. The license fee is affordable and the help desk provides wonderful service (in English) if there are issues. That is of high value in a country were paying for software is not that common. With SharePoint being part of Office 365 I thought it would be great if Project Management, Client Database, Quotations, Invoices and some Accounting is also in Office 365. So I worked with SharePoint tables. But I had to abandon it, because the MSFT cloud server isn't inside China. It is in Singapore and internet in China is more like an Intranet. Fine, at least it works, our data are safe and secure in Singapore MSFT. But performance wasn't good enough to run what I intended to do. Too much data traffic between workstation and SharePoint server. Performance not good enough. Same with Access accessing tables residing in SharePoint. Too slow for daily transactions. AWA works great. Procession is done on the SQL server inside Office 365 license and functionality is good. If we had "Long text" fields in RTF then all would be perfect. But now I am really shocked. Our go live was supposed to be 1 April. A real fools day. Moving to Azure SQL server as suggested by some of you (thank you for caring) isn't an option. I want less complexity and no more monthly license fee. Office 365 subscription should do it. I did this hole exercise to finally retire a FileMaker solution (an of the shelf product with it's own license fee). That product has some major flaws in handling foreign character fonts (Chinese) and managing bilingual data. But I guess I have to keep it. Although it requires an in house server, but the performance is good. Now I study PowerApps. I am optimistic. It will provide new opportunities and look more "modern" in the end. If the performance is ok, then I can work with it. It can do tables with lookup fields. So there is our relational database, right? And we get long text in RTF. If performance isn't good then I need to get it hosted on a server farm in China (MSFT partner). Then it is inside the China Intranet and will run better than in Seattle :-) I will reach my retirement age later this year. That will be a relief too. Then MSFT can retire any product they want. Thank you all. God luck with your AWA conversions.
Regular Visitor
I love my spelling errors

I think the real reason for discontinuing AWA's is the same reason why every IT department in a major corporation hates Access databases - they proliferate exponentially (read that as "take up resources"), are usually poorly written (read that as "never-ending request for help with them"), not to mention the issues with version changes, etc..


The cloud is NOT necessarily a solution for everyone, even for folks who just don't want to have to hassle with maintaining their own on-site IT systems.  Cloud providers have the same headaches as on-site IT departments - managing resources (making you pay for what you use so they can afford it to do so), dealing with user clients (always a problem), and providing desired services (if you don't like it, then just leave it).  Cloud solution providers are not necessarily going to make your technology life any easier than your IT department would, except your IT department works for YOU, so at least you have some control over what happens.


It would be nice if you could have your own CHEAP & SIMPLE TO SETUP AND RUN in-house server resources so you could create your own "cloud" the way you want it and run it the way you want.  Think about it.  We can get a desktop machine for cheap and connect it to the internet ourselves.  Why can't we do that with servers?  I'd love to have some client machines and my own server - all connected to the internet with both a public and private access element.  Make your own cloud!


Granted, this wouldn't be a solution for everybody, and it does have it's own issues, but what solution doesn't?  I know it would make running my business a lot easier - I'd dump cloud providers in an instant!  Hopefully the technology to do this isn't too far in the future!

Regular Visitor

Hi Mark,


What is the difference between AWA and PowerApps in regards your point why AWA have been discontinued. The difference between AWA and Access in desktop version is that the administrator had control of who could create apps.



Regular Visitor
Established Member

working on moving on I looked as Azure database for back end... could not upload app package.  then trying to set up database with SSMS...  no query designer for Azure SQL database... unless you are with SQL server 2016...  you sure can set it up on Azure through VM at a cost os USD 1200 / month

Microsoft, pushing us like that to move on might just end up pushing elsewhere...  Since we have to search for alternatives finding them you might see (me at least) moving everything away from Microsoft, once your fidelity and reliability was put in evidence by such a bad move... and I agree with some posts here : your astonishing silence/lack of management of the original mistake, because taking working service from your customers without a replacement and a short notice isn't anything else...  even if you feel you are loosing money, you don't see part of O365 licences you have was due to AWAs.

Senior Member

Kevin Ichbia, I think you can download SSMS 2016 separately from SQL Server 2016 itself. See https://msdn.microsoft.com/en-us/library/mt238290.aspx This is not my area of expertise, but I am sure you cannot just upload the AWA app package. I think it has something to do with the Dacpac inside the .app file which you can get to if you rename the .app file to be .zip. It isn't something I have tried myself though, so this is (very nearly) a case of the blind leading the blind.

Established Member

Hi Alan, thanks for the message I did download and open SSMS, my issue is that setting up table is rather easy, but for SQL database query graphical designer is greyed out...  and I don't think I can learn SQL to rewrite all my queries in SQL without graphical designer - to have it working per what I read you need SQL 2016 Server... 
You are right on dacpac, it is inside the wrapped app packed once decompressed, but SQL didn't recognize the dacpac package as a database...   now taking a look at postgres on amazon cloud with Pgadmin/workbench/Vfront see if I can work something out...  if I do will post here. 

Senior Member

Kevin, I do hope that it is possible to move the SQL Azure bit of AWAs from SQL Azure-from-Office 365 into SQL Azure proper, otherwise I am going to really, really struggle. Has anyone here been able to move their AWA database (tables, SQL views, data macros/stored procedures) into SQL Azure proper? I note that at the moment we have been given the ability (if it were to work properly) to move our AWA tables into SharePoint lists, which is a complete joke bearing in mind we were told what a wonderful thing AWAs were compared to Access 2010 web databases (which used SharePoint lists) since SharePoint lists were too slow. Would someone from Microsoft please let us know the best way of doing this. Thank you. If push came to shove, I suppose we could move tables by opening AWA tables in Access desktop and converting them into local tables before moving them to SQL Azure using a suitable tool, but that would leave all the queries/view and datamacros/stored procedures.


Over to Microsoft to tell us how best to go about this.

Occasional Visitor

Hi Kevin,  A suggestion that may/may not work for you depending on your situation.  I developed an Access application that uses a SQL Azure database for production.  I keep a development copy of the database on my local machine.  Among other benefits, this enables me to edit views using the graphical query designer.  Scripts generated in the dev database can be used to update the modified objects in the production database.

Occasional Visitor

Hi Kevin,  Re moving the database to Azure SQL:  Here is a possibility I have not yet tried; I need to first get an Azure SQL subscription for the database I plan to move.  In SSMS, right-click on your database and click Tasks.  One of the selections is "Deploy Database to Microsoft Azure SQL Database"


New Contributor

@Allan Thompson"this enables me to edit views using the graphical query designer.  Scripts generated in the dev database"

You can edit views in Access desktop?

Do you use VBA to generate scripts?


Hi Javier:  AWA's were useful to Access folks because they extended Access to the web, but they didn't excite anyone else.  Besides, throwing AWA SQL Server db's into O365 as easily as AWA'a made it was starting to create nightmares for Microsoft.


The cloud is great for web stuff, websites, web technology, documents, lists, etc., but not for running server side SQL databases on O365, unless you have a place on the cloud that is specially designed for that (O365 really isn't - it's a document store).  Microsoft wants to have a system that is not only more interesting to a wider audience, but they want to use the technologies that work best for their cloud environment.  AWA's were NOT one of them.


PowerApps work (supposidly) with SQL Server db's that are on SQL Azure sites as well as other lists sources like Excel workbooks, Salesforce, Dynamics 365 and "Common Data Services" (read that as "lists").  Basically, it's like MS repackaging A2010 AWA's under another name and trying to give them wider scope and audience.


Of course you know what's going to happen... I am already seeing the comments on blogs... the Excel community is looking at PowerApps the same way that the Access community looked at AWA's.  They are wanting to build complex Excel VBA apps with an assist from PowerApps and they're pulling out their hair wondering "what happened to my template?  What happened to the VBA?"


...Anyway... sit back and get ready to watch round two....

Regular Visitor

Hi Mark,


thanks for you input but a few things to clarify. I understand that Microsoft want to specialize SharePoint as a document management (be aware those that us it as Intranet as Microsoft may be thinking to remove this fiction the same way it did for the internet in O365)


the problem here is the way it is done. What you are saying is because AWA is not spread to a wider audience, Microsoft don’t care about those customers. I think one customer should be as important as thousands or millions.


why Microsoft left IE available in Windows 10 when released Edge? And just giving on year grace to AWA.


Anyway it is not affecting me personally but I can't avoid fill bad for those affected that I am sure are more than one.





Appreciate all the comments noted here.  As I said earlier, these are all being seen and read here across the team.  From an editorial perspective, having made our statement, in general, I don't think its right to reply and challenge every opinion.  As we (me!) noted at Ignite last year (https://techcommunity.microsoft.com/t5/Microsoft-Ignite-Content-2016/BRK2297-Discover-how-we-run-Mic...) in the ODSP Change Management session, we are trying to establish a clear pattern for changes in cloud services alongside well understood change patterns for locally installed software.


We know that any removal of an element of Office 365 is going to be met with disappointment, at least.


For me, personally, I was a SharePoint MVP for years before joining Microsoft in 2015.  Back in 2014, pre-Microsoft, I led the first post SP1 session on the release of AWA for SP2013 at the European SharePoint Conference in Barcelona, and I've spoken on it many times since.   There was a lot of interest then, and of course, its disappointing that we all in the community - Microsoft and our users together - didn't make AWA a breakout success. 


Looking forward, from where they were a few years ago, we've been doing a lot of scaling and engineering work on SharePoint lists to make them more responsive, robust, high capacity and high performance.  PowerApps, in my opinion, is a solid early release with a lot of momentum and a lot more enhancements coming soon.  No, its not all complete yet - but I can't wait for May 16 - the SharePoint Virtual Summit -- to show off the next wave of our vision.  Hope you can join us there! https://blogs.office.com/2017/03/21/announcing-the-sharepoint-virtual-summit

Senior Member

Hiya Chris,

Again, thank you (seriously) for keeping involved here amongst a group of angry and disappointed participants, including some whose businesses Microsoft are wrecking. You wrote, "We know that any removal of an element of Office 365 is going to be met with disappointment, at least." Yes, "at least", particularly when it has only been available for 3 years. It is not just "disappointment". Microsoft are destroying projects and some businesses. Why is there just one year's grace for AWAs? If you don't want to destroy projects and some businesses, give us a few years' grace, not just the one year. Surely you know that just one year is not practical.


If PowerApps are going to be able to replace more than just the most trivial AWAs and there is good news coming on May 16th, maybe it would have been wiser to have announced the AWA killing-off after May 16th. Microsoft have gone about this all back to front. If PowerApps is so wonderful and able to replace AWAs, why not just give, say, 5 years' grace and stop screwing us? It would allow for an orderly transition.


Can you not see how conversations are going with our customers?


Conversation 1

AWA developer: You know this solution you have just paid for? Well, you need to pay for another one as this one isn't worth putting in as you'll only get a year's use out of it.

Customer: Please give us our money back and then it will be "Goodbye."


Conversation 2

AWA developer: You know this solution you have installed and is running nicely?

Customer: Yes, good isn't it. We are very pleased with it.

AWA developer: Well, you will need to shut it down within a year. Microsoft are screwing you.

Customer: That's right, blame Microsoft. Give us our money back. We won't want to work with you again. We can't trust you.


Conversation 3 with a charity

AWA developer: You know these AWA solutions I've done for you over the last couple of years and which you now rely one?

Customer: Yes, they work well. Thank you for giving so many hours free of charge. We know you are a very busy man and that it has been difficult for you to do this.

AWA developer: Microsoft have dropped this technology even though it has only been available 3 years and we will have to convert it all to something else with one year.

Customer: How are you going to do that in that in that time scale? What technology are you going to use?

AWA developer: Dunno.

Regular Visitor

Any idea how to port  Access web App package from O365  to  an on-premise hosted SharePoint 2016 server?

in this post "Create an Access app package" it seems impossible



“IMPORTANT: You can only install and reuse Access app packages across the same deployment environment. Installing Access app packages from on-premise SharePoint installations into Office 365 or SharePoint Online are not supported scenarios. For example, if you’ve created your Access app package in a SharePoint site that your organization hosts separately from Office 365 or SharePoint Online, you can’t install that app package in Office 365 or SharePoint Online. The same restriction is in place when trying to install Access app packages created from Office 365 or SharePoint Online into on-premise SharePoint installations.”



Senior Member
Grover Park George has done a blog post on how to move the data side of AWAs from Office 365 to SQL Azure or SQL Server. See https://gpgonaccess.blogspot.co.uk/. I don't know whether it includes moving stored procedures/datamacros or SQL views.
Senior Member
I doubt George's text was on SP2016. We figured it out ourselves. Microsoft said they were going to support it (last november), but I doubt they will. Because it works only with SQL-server 2014 (nothing else), they didn't take as a solution to publish. I can get you the whole mail exchange along with our working combination. You can even export/import an .App file from O365 to OnPremises and cascaded combos etc is there. It even runs better that SP2013 On Premises did with SQL-2012 selected behind Access Web services 2013 in SP-administration It runs fantastically actually. We're delighted to have at least 10 years going with that because we invested big time and it's exactly what's lacking on PowerApps and Flow at the moment.

It's definately possible to load an O365 produced .app package into SP2016 - in fact Microsoft labelled my apps (developed on O365) as compatible with SP2016 in their store descriptions. However, this is not QUITE true. There is one feature missing from Access Services on premise and that is the SendEmail function. Use of this is very central to the apps I've built (for workflow) and on-premise the relevant macro commands are simply ignored (no error, just the emails don't send).


I have also found that the save as snapshot process often times out (tried it recently on a client's system).

Senior Member

Hi Julian, that might mean we can upgrade our SQL-2014 Server to SQL-2016 and get much better performance. Are your Apps running on OnPremises SP2016 or are they available for that at the Microsoft Store? We had quite some issues to get an .App file imported (that was exported from SP365).

Senior Member

Here's what my colleague reported on this in December.


: Gerard Timmerman
Verzonden: zaterdag 17 december 2016 11:48
Aan: Rob Koelmans
CC: Alexandru Scutar (Rinf Temps)
Onderwerp: RE: exporting - 1161201115010214


I continued this morning with replacing the SQL features on both the Application and Front-End farm-members with SQL2014 featurepack and SQL2014localdb + SQL2016 Management studio 16.5.1 and finally was able to import a 365 export!

The SQL server is now the same SQL2014RTM version as in the 365 apps.  


He figured things out with this: https://support.microsoft.com/nl-nl/kb/321185#bookmark-sqlserver2014 

It was the only combination that was allowing for importing apps that came from O365

Hi Rob


My apps are all on O365 as far as I am aware - they are supplied via the app store. Unfortunately moving them to on premise is not an option - a) they can't be moved as they are locked etc, b) On premise doesn't run SendEmail so none of the workflows would work and c) I don't have any servers or anything so couldn't support customers - and I would no longer be able to provide updates via the app store so the whole business model would be broken.


There is no MS alternative until / if Power Apps/Flow/CDS apps can be delivered and maintained through their new store (can't remember the name) - and that these tools can provide suitably rich Web (and mobile but web is more important) UIs. Also, the pricing model of Power Apps and Flow will probably mean that this wouldn't be commercially viable either because customers would be able to buy complete HR solutions for LESS than the platform licence (given that every employee would need a licence).


My options are definately zero in the MS world at the moment - but there are options in the market, some of which are very interesting.


I guess I just have to accept that my Sharepoint app business is over and move on.



Occasional Visitor
Giorgio ROVELLI - By the graphical query designer, I meant the "Design Query in Editor" that is available in SSMS .. except when you are working with an Azure database.


Established Member

To Microsoft... 
What is shocking of the situation and generating angry posts is that you are announcing shut down of the service without giving any option/guidance whatsoever so as to satisfactorily port the AWA apps we've built....  "it's finished, that's it, work it out with lists/powerapps/flow/CDS, they're not yet up to the task but we're sure you'll be ok" 
To start with, export to sharepoint lists didn't work for me on most tables (I guess because of data macros), they do not ensure referencial integrity or full relational capabilities....
Have you seen how many questions referring simply to how to move the back end???  "Maybe" you should have thought of that first before announcing a shutdown...   if you'd said "we're going for a change you may port your apps there, that way - with relative ease" everybody would have followed with little comment...   in this case you have not proposed a change, but dictated an end.

Given the circumstances, I agree with other posts there logical thing to do is to extend service considering giving your AWA community a minimum app life cycle (I am not talking about a year, maybe 5) and come up with a suitable replacement...   this is a question of decency and respect to people buying and using your product....  and if you're losing on this one, consider it an investment towards your customer base - Bill gates is still the richest man on earth for now...

Senior Member


If you have to reconsider later on, the iFrame can be a good alternative to SendMail(). We have a very simple PWS-service, a WebAPI service that can start any PowerShell script. In between we have a GetToPost service: we put a request message on a table. We place an URL in the iFrame Control with a ticket-id. The GetToPost retrieves the message request and performs the requested message (in this case apply a post-url to the PWS-service).


The response of a called service is put back to another table in the AWA-database. The trigger may issue a new request on the first table, so - after placing a response - every service checks for a new request with the same ticket on the second table and so on.


Most of the time, the requests concern replications requests of an encapsulated request to another AWA-database. Each AWA application can have one or more webservices they can only call themselves. Every AWA supports replication.


Just create a very simple Get-Webservice that you can call from your AWA. I'm not sure how long the URL string may be, but it may be long enough for you to support a workflow process. Www.asp.net has very simple WebAPI 2.0 sample that you only have to extend with a mail send.


Ps, you also don't need the logon information from your database that you only get with loading the app in Access. With Powershell or by hand you can create an admin account that a WebAPI service can use for every database in a server. This may look unsafe, but it makes no difference if you have a webservice that uses respective accounts for each database or one account for all.

Frequent Visitor

Alan, FWIW, I tested the process of moving the database from AWA into local SQL Server using .dacpac and it works well.  Triggers, Sprocs and Views are indeed included.  By using the 'Export Snapshot' to get the .app file from Access you get all the data as well.  Nice!  I wish LightSwitch had the option to download data from auto-hosted apps back when they shut us down with few months notice.


Steps are as follows:

1 - In Access Export Snapshot

2 - Rename .app file to .zip & extract .dacpac file

3 -  In SSMS connect to SQL server 2016

4 - Right-click on Databases > Choose 'Deploy Data-tier application'

5 - browse to .dacpac > Name the new database > Done


That said, the database is quite 'Access centric'  In other words it's a lot like opening an .mdb and showing system objects.  There is just a ton of stuff that is not needed outside of AWA.  For example, there are many AccessSystem objects and all stored procs have a bunch of trace logging wrapped around your custom logic.  I suppose this isn't a problem, but change maintenance could be a mess using this databse as-is outside of AWA designtime environmente.


But at least you have a way to get your data.


Since Mr Gates was mentioned, thought I'd share a quote:


"Your most unhappy customers are your greatest source of learning." ... Bill Gates

Occasional Contributor
Hi Chris / Microsoft, First, please do not shock us again posting this: Comments are Closed! If you are listening/reading, you should agree that there are problems you have already created for dozens of developers hence affecting thousands (possibly millions) of users. Affecting? Better say: Destroying. So please stay with us here until things are resolved. We love PowerApps, Flow and Power BI, but please read this well: THEY ARE NOT READY yet as serious business database solutions. For instance, even with the expensive premium subscription of PowerApps, wherein I can use the future of SQL (as said by Microsoft), CDS are not ready: No Queries, No Data Macros, and No relational database can be straight forward displayed in a single screen in an App (a screen connects only to a single Entity). These are 3 issues amongst tens of others have been posted in the community forum of these products. PowerApps CDS now are no more than toys: they deal with a single Sheet/Table/Entity. PowerApps should be a PLUS to AWA means it should make the best of PowerApps then go to improvements. You say removal of an element of Office 365 is going o be met with disappointment. these are nice words, but they do not reflect the fact. The fact is that you are removing millions of records in relational databases, and this has not been met by disappointments, it is being met by shocks, collapses, and tragedies! We love SPO new Lists, but again, they are not ready to replace AWA. I can understand that Access Desktop and AWA are profitless to you, in the era of cloud! We don't mind that you make the best to Microsoft, but please make it right, make us continue admiring Microsoft. I am myself not a developer, but our of ease and trust in AWA, have learnt it, them made +10 Apps for my multi-branch business, serving hundreds of customers, and already have pushed many of my friends use office 365 because of AWA. The Summit? looking forward: lets see. Until then, please CANCEL the announcement of shutting down AWB in a year plus a month or 2, it has been a mistake you have done, and better you correct it. On user voice, there are at least 3 ideas on AWA I shared, and Microsoft thanked me for, and said they are under review. Imagine! but anyhow, do not develop AWA, the way it is now is okay for us, until new technologies are fully ready. I am tried of explaining things.

Dear Chris,


Today i have (had) a plan...


My plan was that i write a personal letter to you and your team, with the question, why?


And I wanted to say a few things.... but the letter from Yahya hits exactly what i was planning to write. 


But the real truth of shutting us down, and our businesses, is not clear to me. And I think for many people.


I think it's all about money... true? No?


So please tell us..... Why?


Why is it this way?

Regular Visitor
Chris McNulty, I am not sure why you suggest the Microsoft PowerApps might be used to do what we are doing now with AWA. I went to study PowerApps with a positive attitude, but I cannot see how these two platforms compare at all. Do you know AWA? It is a database that lives in our Office 365 subscription, is hosted in the SharePoint cloud. At least that is how I think about it without using more acronyms (AWA = Access Web App). The Northwind database has been with us since the last century. If you can implement it in PowerApps, then you can start talking about replacing AWA with PowerApps. I have implemented the Northwind application with some modifications to fit my business in AWA. It works great. Has good performance and all is covered with the Office 365 business premium license fee. There was a little hick-up when Microsoft changed the license model last year and we had to get an enterprise license for a while just to be allowed to work with Access, but that situation was remedied quickly. Because it was a bad decision to take Access out from a license call Office Premium. Your posting here revealing AWA is dead is another big mistake that needs to be fixed. Office 365 is perfect for small business that do not want to manage in-house servers. We don't have enough brains to manage our own SQL server. And PowerApps is just a sexy front end to something that has no substance. Maybe it will be one day a fully functional replacement for AWA, but then please keep AWA hosted on our Office 365 SharePoint until then. I cannot express here how angry I am. In 2016 you guys just improved AWA and now you want to pull the plug. Please help me to understand. What does it mean: "We will stop creation of new Access-based apps in SharePoint Online starting June 2017 and shut down any remaining apps by April 2018."? - My existing AWA system will stop working in April 2018? - I cannot make any more changes to my AWA system after June 2017 to fix a bug or add functionality? Is there a way to get someone to reconsider this decision?
Senior Member
Chris McNulty, May I ask what your own experience is with AWAs? Have you ever created a non-trivial AWA? If so, how did you get on converting it to PowerApps?
Regular Visitor

AWA : it's also a WebApp for desktop, Speedier than Sharepoint List or PowerApps, Easier, more Functionalities (eg : copy-paste from Excel in datasheet view with a data macro on insert), more stable, with a Subscription cost included in O365, operational, efficient, no bugs and we don't need to re-developp a new sofware.
Mobile First is great but not for all projects, sometimes it's better Desktop First and Mobile Friendly. I don't mean Desktop Access because it would be a backtracking.
If you want to stop AWA then you need to provide a complete alternative that will satisfy everyone since AWA currently works very well and meets a need. Moreover, we know these drawbacks in advance, but we are not caught off guard as you currently do.
How can we explain to ours customers that they will have to pay again a development in a few months. What arguments aside microsoft stops the product.

I have ben considering whether PowerApps could ever be a home for my apps from a commercial point of view (particularly HR) and have realised that it really can't be. Ironically, there is even an example of using PA for an HR process on the Power Apps licencing page:




In the example the article highlights that all 700 employees would require a Power Apps level 1 licence - which is $7 per month. Now this is 2 - 3 times MORE than a typical licence for a full blown SaaS HR application. So on this basis you really couldn't base an HR app on Power Apps and be in anyway competitive.


So, Power Apps isn't there technically and commercially impossible - my only market would be companies who have already committed to Power Apps licences for ALL employees - and there won't be many of those I shouldn't think.


Need I say more!

Established Member

@Chris McNulty and Microsoft : 
Please tell us after 10 days of this what will it be?
- service extension?  for how long? with same proporties? 
- real replacement ? how/where to easily/practically implement it? at what cost? etc...
I think we should reasonably be looking at a combination of both.

If you have a wonderful solution you reserve for your May conference, you might have waited till then for your termination announcement.  Now announcement is out, if it is the case, give us the premiere here.

Otherwise a third option would be to ignore customers and be ready to lose them... not only the few people like us that have been working with AWA but people who moved with them to O365 for example on the way... which somehow I take you must consider given how this annoucement is kind of under the radar...  didn't see much about it anywhere else...

But first is first for now, I never wondered because I thought being with Microsoft on SQL would last close to forever...
I don't have on premise SP
I could not connect AWA back end to SSMS though SQL connector - says firewall rules (though everything enabled) don't allow it
I did open back-end with Visual Studio (I really don't master) through ODBC but couldn't find a way yet to copy/migrate the DB.
We need an easy/satisfactory solution for that... if you shut down AWA service, you owe your customers right to move their data adn schemas to wherever they please in satisfactory way, and that should come before any shut down notice. 

For the rest, with or without Microsoft if you don't care, be sure we'll indeed get along, we don't know/have time to learn how to code, but ideas we have plenty...  we'll hopefully don't get there...  so please refer to my first questions, and above all to back-end portability and give us some REAL ANSWERS worth being called so.



Senior Member

Should we start looking at Flow as Microsoft may deprecate 2013 Workflow Manager soon?

Frequent Visitor

 @Julian Kirkness I have to say that your software (and all the advice you so freely posted) and a great community was the inspiration for me picking myself up from the Lightswitch fiasco, signing up again as a Microsoft partner, Convince a client with 70+ IT Auditing consultants to dump G-Suite in favor of Office 365 SharePoint Online, use AWA to develop a CRM, Job and Time tracking application that was implemeted in Jan this year. They absolutely love it. I have several other clients in the pipeline and all of it has just been canned in a way I have not seen any major organisation do in my life (including Lightswitch which had a five year promise to continue). How sad, disappointing and frustrating. I also used Powerapps to do the time sheet entry and it was just o/k however the integration to AWA SQL was at best terrible, espescially multi table lookups and dates. For Microsoft to suggest converting to this and sharepoint lists is possible, is disingenius and unethical.


I have to now draft the letter to the client and I honestly dont know where to begin. Perhaps I should ask Microsoft for a refund first. Honestly this is a disaster.


Simply extending the life of the product to a reasonable period would give people a chance to act.


Thanks again for all the commentary and guidance on the future of no code business solutions in Office 365 and SharePoint.  Some additional points of correction to some of the earlier posts: 

  • PowerApps and Flow are available at *no* additional cost ($0/monthly) for Office 3675 commercial plans, including our newly announced support for K plans (deskless frontline workers.)
  • Modern SharePoint Lists continue to be re-engineered to support ever larger enterprise scale and scenarios, in part to help them take on a greater role in succession to legacy data platform solutions
  • The on-premises data gateway also allows you to integrate on premises SharePoint & SQL alongside the dozens of cloud-based connections supported intrinsically by PowerApps, Flow and Power BI.


A few additional resources:

  1. Our guidance on porting apps from AWA to PowerApps and other successor platforms: https://support.office.com/article/ff9d9058-14cf-40a2-89c8-ec46cf5cd67c
  2. Learning more about building PowerApps: https://powerapps.microsoft.com/en-us/guided-learning/
  3. Our May 16 SharePoint Virtual SUmmit: https://blogs.office.com/2017/03/21/announcing-the-sharepoint-virtual-summit/