The Evolution of Microsoft Project to Planner Premium

TL;DR

  • Project Evolution: Project Server (on-premises) > PWA (SPO) > Project for the Web (Dataverse) > Planner Premium (M365+Dataverse)
  • Licensing: Planner Basic (included in M365) | Planner Premium (add-on P1, P3 or P5)
  • Customization: Currently supported for P1, P3 or P5 licensed users using Power Platform Microsoft Project Service Core solution in dedicated environments
  • Reporting: Use Power BI desktop client connecting to Dataverse tables
  • Teams Integration: Use Planner app for plans created in default environment (out of the box plans) & Project app for plans created in dedicated environments (customized plans)

Overview

Over the past few years Microsoft Project has been going through some major changes. Not just from a functionality perspective, but rather from an evolution, branding and re-platforming perspective. Microsoft Project has been one of the more challenging on-premises platforms for Microsoft to transform into a true cloud service. In this article I will review at a high level the re-platforming and evolution of the product into the service it is today and clarify some of the confusion around its branding and integration with Microsoft Planner and what Planner Premium really means.

Planner Premium on the Timeline view

Microsoft Project’s Transition to Project for the Web

For a full history of Microsoft Project, check out the Microsoft Project Wikipedia page.

The PWA era

In the early 2010s, along with the transformation of BPOS to Office 365 (O365), the predecessor to Microsoft 365 (M365), Microsoft started implementing Project Online as an O365 add-on service utilizing Project Web Access (PWA). PWA is essentially a SharePoint Online (SPO) site dedicated to hosting Project MPP files using a Project specific SPO site template. The site template includes pages and lists for things like projects, approvals, tasks, resources and reports.

PWA Landing Page

The idea was that Microsoft Project desktop client users would open the MPP files hosted in the dedicated SPO site and continue to work as they always have. Licensing was based on the on-premises licensing approach and didn’t change much. PWA is still supported today (as of 2025), and you will find that many current project management professionals are still using this approach.

Since most project management offices (PMOs) and project management professional were the typical heavy users of Microsoft Project, they tended to use Microsoft Project Server and were content to continue the use of Project’s on-premises implementations, even if they were hosting the files in SPO.

The Dataverse Era

In 2020, Microsoft moved to making Project Online a true cloud-based service and not just a holding area for MPP files in the cloud. They built a web application hosted at project.microsoft.com and re-branded that implementation as Project for the Web. You can find Microsoft’s features description on the What can you do with Project for the web? page and the service description on the What is Project for the Web page?. They used the Dataverse database in the Power Platform’s default environment as the backend storage for the service. You can find more on how to implement Project for the Web on the Microsoft’s Deploying Project page. You can find guidance on how to integrate Project for the Web and PWA on the Integrate Project for the web into your project management processes page. Also note that Microsoft also developed some Project for the Web accelerators which are documented at the Enhance your projects with the Project Management Office Accelerator page.

Before an organization gets a license for Project for the Web, they will get the following screen when visiting project.microsoft.com.

Project for the Web without a License

Once an organization enables & gets licensed for Project for the Web, a Power Platform solution called Microsoft Project Service Core gets deployed to Dataverse in the default environment automatically by Microsoft and your licensed users can start to make plans.

Project for the Web Landing Page

Notice the link at the bottom of the screen labelled “Go to Project Online ->”. This link will take you to the PWA page on SPO (where you can find previous MPP files hosted). This and Microsoft’s documentation refer to PWA as Project Online and Project for the Web isn’t Project Online. It’s important to note that it’s an evolution of the Project Online service offering, from cloud hosted projects (MPP files & associated pages/lists) to a true cloud hosted project management service application. Microsoft posted a page called Project for the Web and Project Online to help explain the differences. They also posted another page called Project for the Web and Project Online desktop client to explain how to use Project for the Web from the desktop client. A service description for Project Online, Project for the Web and the Project Online desktop client can be found at the Microsoft Project service description page. However, the rebranding doesn’t stop there.

Project for the Web’s Evolution to Planner Premium

Introduction of planner

Around the same time that Project for the Web was being rolled out, Microsoft added a new task management cloud service application called Planner hosted at planner.cloud.microsoft as part of the M365 suite of tool and was included as part of the standard M365 licensing scheme (not an add-on like Project for the Web). More information on managing Planner can be found on the Microsoft Planner for Admins page.

This application was targeted for project management “lite” scenarios. Scenarios where users don’t have or need deep project management capabilities and experiences. Of course, Planner and Project for the Web were seen by many as somewhat competing products, and it seemed that most of the new development was in Planner and not in Project for the Web. This added to the confusion already happening between Project for the Web and PWA. Not to mention that these weren’t the only Microsoft task management applications being offered either.

This year Microsoft is rebranding Project for the Web now as Planner Premium. The intent here is to consolidate the project management service offerings into one brand: Planner. The Planner plans that come with M365 are now called Planner Basic. The Planner Premium delineation is to designate that what used to be called Project for the Web is still going to be licensed as an add-on and are currently called Planner Plan 1, 3 & 5. You can find more details on each of these plans on the Compare work management offerings page.

The consolidation isn’t only about licensing, but also the interface as well. Below you can see that in the planner interface you can now create Planner Premium plans:

Planner Plans – Basic & Premium

Once you create these Premium plans, the feature set you will see will depend on the license assigned to you and will look like the first image in this post labelled Planner Premium on the Timeline view.

Integrations with the Power Platform Applications & other M365 Services

Non-Default Environments

Project for the Web solutions in the default environment have significant access limitations (generally read-only access) as the default environment is not intended as a development or custom solutions environment.

The Microsoft Project Service Core solution can also be deployed to Power Platform dedicated environments intended for development or hosting custom solutions. What this means is that you can provision Project for the Web plans using Dataverse tables in a dedicated environment where you have full control and can build other full control applications on top of the Project for the Web backend data. Users can still access all their plans on project.microsoft.com, whether the plan’s data is in the default or dedicated environments. More information can be found on the Deploying Project for the web page.

Dataverse & Power Automate

The backend data (whether deployed to the default and dedicated environments) is stored in Dataverse tables provisioned by the Power Platform’s Microsoft Project Service Core solution. This backend data is browsable if you have Power Apps maker rights. In addition, you can use the Dataverse connector in Power Automate to setup triggers and perform actions against the backend data in standard tenants (depending on tenant specific admin controls). Instructions to do this can be found on the following pages:

Power BI

Project reporting can be created in Power BI. Refer to the following pages:

Microsoft Teams

You can access all the flavors of plans and tasks in Microsoft Teams via all the following Teams apps.

TEAMS’ APPUSER CONTEXTCHANNEL CONTEXT
PlannerUsed to show all the plans and tasks the user is associated with from To-Do, Outlook Tasks, & Planner (including Premium plans) created in the default environment.Used to show a plan and tasks the team (M365 group) is associated with from Planner (including Premium plans) created in the default environment.
ProjectNot supportedUsed to show a plan and tasks the team (M365 group) is associated with from Project for the Web. This includes plans created in the default and dedicated environments.
SharePointNot supportedUsed to show a PWA site.

LIMITATIONS: Currently the Planner app only support Planner Basic & Premium plans and tasks created in the default environment. I would expect that plans and tasks created in dedicated environments will eventually be included, but not anytime soon.

Are we there yet?

As of the time of this post, the only significant or key limitation is the ability for Planner Premium to include with plans created in Power Platform dedicated environments in order to support plans that can be used with fully customizable applications and fully support Dataverse triggers and actions.

Related

  • Best practices for setting up Planner Premium plans…coming soon.
  • Configuring Power Automate triggers & actions for Project plans…coming soon.
  • Working with Dataverse choice fields in Power Automate…coming soon.
  • Provisioning Project plans in dedicated environment…coming soon.
  • To delegate or not to delegate, how best to provision M365 resources in Power Automate…coming soon.
  • Automatically adding Teams channel tabs for Project plans, Power BI reports & Lists…coming soon.

QnA Maker

Bots and AI are all the rage these days as the next technologies promising to improve productivity, build efficiencies and capabilities that don’t exist today, change how humans engage with technology, and change the world.

You can see these technologies in play today in Alexa, Google Home, Siri, and Cortana.  These technologies have been integrated into laptops, tablets, and phones.  These same technologies have also spawned whole new families of consumer devices such as the Amazon Echo and other personal assistant devices.  These Bots and AI will eventually be deeply integrated in every device, application, and service.

The most basic and common use of bots has been developing Question and Answer solutions, such as Knowledge Base information and FAQs.  You often see this in adds for the new class of personal assistant devices…”Alexa, what’s the weather tomorrow?”, “Google, who won the Super Bowl?”, “Siri, how far is the north pole?”.  In these cases, the knowledge bases are Search Engine results, which are queried, indexed based on relevance, and read/written back to the user.

The thing about bots is that they can outperform a search engine. Search engines don’t generally give you answers to questions. They give you the source of the answer to your question. You still have to read through the sources to find the answer.  A bot, on the other hand, can actually answer the question directly, providing a link to the source for reference.

As for Office 365 and other Microsoft applications and services, they released the Bot Framework for developers to integrate into their applications.  The first service that Microsoft natively integrated bots into was Microsoft Teams (using a variation of the Bot Framework). Rest assured that it wouldn’t be long before they are integrated into all of Office 365 and other Microsoft products (including SharePoint on premises) for basic application and service based questions.

What’s most important to businesses (i.e. Office 365 customers) however is that bots will allow employees to add frequently used, business relevant and critical knowledge bases to Office 365 (including Teams, SharePoint, Outlook, etc.).  This can all but solve the age-old findability problems for most of their business-critical content, resources, and other assets without employees taking the time to search and identifying relevant results.  This is a game changer for most businesses as they can see huge productivity gains!

Up to now, implementing the Bot Framework or bots into Office 365 requires a developer to implement a bot.  This is why most organizational bot development examples thus far have been FAQs.  Although developing bots allow for big capabilities and potential for business beyond Question and Answer problem, it is a too common use case to need development efforts at each organization.  Microsoft has recognized that re-inventing the wheel here for every organization isn’t wise and has come out with the “QnA Maker” (in preview) to address this common need.  It also allows organizations to start building bots without needing development projects.

With the QnA Maker, the time-consuming part is populating the list of questions and answers to start. Once it’s set up, it’ll be smooth sailing. And you’ll save massive amounts of combined searching time within your organization.

QnA Maker

I first learned about the ‘QnA Maker’ from the good people at BIZZY.  They have SPFx solutions to integrate bots into SharePoint Online, take a look…

Microsoft Writing Style Guide Released

The goal of the Microsoft Writing Style Guide is to help editors, technical writers, developers, marketers, and anyone else in IT write better content.

Since 1995, Microsoft has provided writing guidelines to editors and developers. The new Microsoft Writing Style Guide brings the guidance up-to-date for 2018 and is an evolution of the Microsoft Manual of Style from 2012. The principles and guidelines in the guide are the same as those used by internal Microsoft writers, which allows consistent quality and style across all apps and content.

Microsoft Writing Style Guide Released

Download PDF version

Some of the topics include:

SharePoint & OneDrive round-up from #msignite

When Ignite 2017 closed, like many others, I’m was blown away with all the updates…Its like they actually listened to most of my customers’ asks for the past 5 years and finally got around to implementing them.  The shear amount of updates is what is mind blowing!  SharePoint and OneDrive are almost a complete revamp after they finish with pushing out all these updates.  This isn’t to mention all the integration improvements with all the other O365 products, services, and apps.

Nick Brattoli from Collab365 has written a great round-up of all the updates.

Andrew Connell also wrote a great round-up of all the SharePoint Dev specific updates.

Below are some of the things that I found worth noting as major announcements:

  1. Greatly improved analytics (including file view)
  2. SharePoint Framework (SPFx) Web APIs & Permission Scope access
  3. SharePoint Framework (SPFx) ALM APIs & Permission Scopes
  4. Files on demand for OneDrive & SharePoint
  5. SharePoint HUB Sites
  6. Self-service OneDrive restore
  7. Universal Sharing interface, no matter which application you are in
  8. No Microsoft account needed for sharing securely
  9. Group enabled site collections will finally be listed in SharePoint Admin center
  10. SharePoint Framework (SPFx) tenant wide deployments
  11. SharePoint Site Collection App Catalog
  12. New SharePoint Admin center
  13. File preview for 270+ content types
  14. Page embedded Microsoft Forms & custom forms via PowerApps
  15. Microsoft built migration tool
  16. SharePoint Server 2019 – on premise (along with Office, Exchange, and SfB 2019)
    • Note that the SfB client is planned to be integrated with the Teams client…I therefore expect the branding of SfB Server 2019 will change before release
  17. General improvements and improved integration to many of the other O365 apps and capabilities (SPFx, Search, Groups, Teams, Planner, PowerApps/Flow, PowerBI, Reporting, Security/Privacy/Compliance, etc.)
  18. SharePoint Conference NA

Others have been voting on their favorite features.

SharePoint 2013/Online Client Components SDK, are they the same thing???

I have been using the SharePoint 2013 Client Components SDK for more than two years now to develop console apps against both SharePoint 2013 and SharePoint Online.  This worked pretty well for me as then I could build a single console app that deploys solution assets to On-Prem Development environments and then deploy those same solution assets to Office 365 for integration, UAT, Staging, and Production environments.

As of September 2014, things changed!  All of a sudden there were two SDKs, a “SharePoint 2013 Client Component SDK” and a “SharePoint Online Client Component SDK”.  Both SDKs are named “sharepointclientcomponents_x64.msi” and sharepointclientcomponents_x86.msi” (x64 and x86 versions respectively for each SDK).  I was about to think that these are the same SDKs, but targeted for the On-Prem/Online environments only.  Then I looked at the file size and was confused…

SharePoint2013ClientComponentsSDKSharePointOnlineClientComponentsSDK

Why are these files named exactly the same name and published exactly the same date, but are different sizes???  So I started digging to find the answer…

After some searching, I found out that the version numbers of the SharePoint 2013 Client Components SDK is version 15.  This makes sense as this matches the version number of SharePoint 2013.  The publish date indicated to me that this SDK included all the changes from SharePoint 2013 Service Pack 1.  This is the same SDK I have been using all along for the past two years, but updated from Service Pack 1.

I also found out that the SharePoint Online Client Components SDK is version 16.  This is the version number for the next version of SharePoint On-Prem (SharePoint 2016 presumably).  At first I thought that was strange, but then after all the news and changes that Microsoft has been pumping out regarding the changes over the past year in Office 365 and the news that some (not all) of these changes will be pushed into the next On-Prem version, it started to make sense.

Here is what I think happened (only my perceptions from everything I could find out up to this point)…

SharePoint 2013 and SharePoint Online were using the same codebase (assemblies) up to the release of SharePoint 2013 Service Pack 1.  From that point on, SharePoint Online’s codebase version changed to 16 to reflect the new development in SharePoint Online only as promised by Microsoft when they beat us with their “Cloud First” strategy message.  The fact that the version number changed in SharePoint Online was first pointed out and documented by Gary Lapointe in his post “SharePoint 2013 Version 16.0.0.1810???”: http://blog.falchionconsulting.com/index.php/2013/08/sharepoint-2013-version-16-0-0-1810.

So what does this mean for developers and SharePoint ALM???

Well, in general we can no longer use the same codebase to deploy solutions for both SharePoint On-Prem and Online as they are likely to never be the same again (with On-Prem always lagging by a major version number).  Online development must start in a SharePoint Online development site and deployed/migrated to different tenants/site collections using the SharePoint Online Client Components SDK.

If we want to deploy the same codebase to both On-Prem and Online, then we will have to use the SharePoint 2013 Client Component SDK, but can not use any of the new capabilities of the Online version.  After reading “Evolution of SharePoint”: http://blogs.office.com/2015/02/02/evolution-sharepoint, this now makes sense.  Dan Holme did a great job explaining the news in detail on his post “The Evolution of Microsoft, SharePoint & Office 365”: http://www.itunity.com/article/evolution-sharepoint-office-365-856

Now if you do start with the SharePoint Online Client Component SDK and you want to target your solution to SharePoint 2013 (or vice versa), then you can follow “How do I run the Office 365 Developer Patterns and Practices against SharePoint 2013 On Premises”: https://github.com/OfficeDev/PnP/wiki/How-do-I-run-the-Office-365-Developer-Patterns-and-Practices-against-SharePoint-2013-On-Premises.

New Guidance from Microsoft for Packaging and Deploying SharePoint Solutions

Microsoft is recommending that developers stop using SharePoint’s Feature framework and list, web, and site templates in their solutions.  Now, instead of defining SharePoint content in CAML, Microsoft wants everyone to start creating content programmatically using the remote provisioning pattern.

http://blogs.msdn.com/b/bobgerman/archive/2015/01/31/new-guidance-from-microsoft-for-packaging-and-deploying-sharepoint-solutions.aspx

SharePoint 2013 SP 1 Release

SharePoint 2013 Service Pack 1 has been released (re-released). Note that while Service Pack 1 does support Windows Server 2012 R2, Windows Server 2012 R2 support requires a new SharePoint 2013 with Service Pack 1 ISO to be released. Slipstreaming or installing RTM and then SP1 on Server 2012 R2 is not supported.

Foundation: http://support.microsoft.com/kb/2880551

Server: http://support.microsoft.com/kb/2880552

Project Server: http://support.microsoft.com/kb/2880553

Foundation Language Pack: http://support.microsoft.com/kb/2880555

Server Language Pack: http://support.microsoft.com/kb/2880554

Office Web Apps: http://support.microsoft.com/kb/2880558

Office 2013 Client: http://support.microsoft.com/kb/2817430

List of Server Updates: http://support.microsoft.com/kb/2850035

List of Client Updates: http://support.microsoft.com/kb/2850036