Support update for SharePoint 2010 workflows in Microsoft 365

[Chris McNulty]

Modern business process is essential for transforming organizational productivity in Microsoft 365. Since the release of SharePoint workflows, Microsoft has evolved workflow orchestration to not only encompass SharePoint, but all the productivity services you use with Microsoft 365 and beyond.

Microsoft Power Automate connects to all Microsoft 365 services and over 220 services to let an enterprise build custom workflows. With the continued investment in Power Automate as the universal solution to workflow, Microsoft is retiring SharePoint 2010 workflows.

SharePoint 2010 workflows will be retired in 2020

For customers using SharePoint 2010 workflows, we recommend migrating to Power Automate during 2020 to maintain continuity in any business process.    

• Starting August 1^st, 2020, SharePoint 2010 workflows will be turned off for newly created tenants.  
• Starting November 1^st, 2020, Microsoft will begin to remove the ability to run or create SharePoint 2010 workflows from existing tenants.

SharePoint Modernization Scanner

To understand if your organization is using workflow 2010 or begin planning migration to Power Automate, we recommend that customers run the SharePoint Modernization Scanner tool to scan their tenants for legacy workflows usage. Using the Workflow Report generated by the scanner tool, customers can understand the following:

• Distribution of legacy workflows across SharePoint 2010 and SharePoint 2013 workflows
• Distribution of out of the box and custom legacy workflow usage
• Which sites and lists use legacy workflows
• Power Automate upgradability score indicating how well the detected actions are upgradable to flows with Power Automate

Using the Workflow Report along with site information, tenant administrators can work with their users to plan the migration of legacy workflows with minimal interruption.

SharePoint 2013 workflows remain supported

SharePoint 2013 workflows will remain supported, although deprecated.  However, we recommend customers move to Power Automate or other supported solutions, such as those from Preferred members of our Microsoft 365 Business Apps Partner Program.

Starting in November 2020, SharePoint 2013 workflows will be turned off by default for new tenants. Microsoft will provide a PowerShell script to let customers to activate the SharePoint 2013-based workflow engine for tenant as needed.    

Use Power Automate with Microsoft 365 licenses

All Microsoft 365 licenses include usage of the Power Platform for customizing and extending Microsoft 365 applications. This includes both Power Automate and Power Apps.

Power Automate also has additional premium features that you can buy on top of your Microsoft 365 licenses. To learn more about what specific features are included with Microsoft 365 licenses go here.

SharePoint Server support for SharePoint 2010 and SharePoint 2013 workflows

SharePoint 2010 and SharePoint 2013-based workflows will continue to be supported for on-premises SharePoint 2016 and SharePoint 2019 Server platforms until 2026.

SharePoint Designer 2013
SharePoint 2010 workflow creation with SharePoint Online using SharePoint Designer 2013 will be turned off for any newly created tenants starting August 2020 and existing tenants starting November 2020. SharePoint Designer 2013 will work with SharePoint Server 2019 for the remainder of the client support lifecycle (2026). SharePoint Designer 2013 will not be supported beyond that timeframe.

Summary

We recognize that these changes may require additional work for some of our customers, and we’re ready to provide support during this transition. We are encouraged by our customer successes, and our ongoing investment in business process modernization in Microsoft 365 on the Power Platform. We’ll continue to share updates through our support articles at https://aka.ms/sp-workflows-support . Thank you.

[HansTeunis]

What!! This can't be true! SharePoint 2010 workflow are still heavily used in sharepoint environments! It's functionality to update permissions is unmatched in either SharePoint 2013 workflows or Power Automate! Support of SharePoint designer 2013 is supposed to continue until 2026 according to https://support.microsoft.com/en-us/lifecycle/search/11674 And now we need to migrate all SharePoint designer workflows to Power Automate in a couple of months. These timelines are madness!

Thx @Denis Molodtsov for starting a UserVoice item for this..

Vote to postpone the retirement of the Workflow 2010 engine to a more reasonable date: https://lnkd.in/ePBDVgG.

800+ votes for this idea in less than a week, lot's of comments, I would say this message hit an open nerve Chris... Is this really the way Microsoft wants to instill a sense of trust in the relationship with both customers and partners?

[Pieter Veenstra]

At first this might be a bit of a shock for many, but really, why would you still have SharePoint Designer workflows in SharePoint Online. I guess for people that went for the quick migration to the cloud and stick to old technology this could be a bit of a shock. I'm glad that I upgraded my clients to Power Automate as soon as possible. Power Automate is a better option anyway.

For on-premises  installations of course it is a completely different story.

[HansTeunis]

Power Automate is the way forward, but we all have a history we cannot simply discard. In this history for instance I know businesses use the 2010 capabilities for automated permissions management of sharepoint content. Power automate is not as versatile in this. Its only recently released permissions management action can not handle sharepoint permissions groups. Never got the api call alternative working. Now all of a sudden time is running out! Also the 30 day limit of a running flow is not something that is easily circumvented, coming from a no time limit solution.

It is all about trust and managing expectations. The product lifecycle promises support until 2026. So much for that. Who's next? Infopath, also supported until 2026... surely need more than a few months to get all of those into Power Apps, if at all...

[Rodney Parrish]

Agree that this is getting to be a habit where the dates we've been given cannot be trusted. We use these product lifecycle dates to plan for depreciation but when an announcement comes out like this, that effectively changes support for SharePoint Designer [might I remind you that the workflow types in SPD 2013 are part of the tool and "supposed" support?] by nearly six years, that it does come down to a matter of trust. I agree with the statement about InfoPath, and despite the above I would not "trust" that your 2013 workflows will be safe either. 

Yes, I hear you when you say why are you using legacy workflows when you should be using the newer ones available. Actually we are. And we use the end of support dates to "plan" since many of my peers globally who have been in the business long enough have been using SP Designer. To have plans escalated six years.....is ridiculous. I'm sure there will be a lot of uproar over this. 

Finally, all of us use legacy tools. If you use IE11 to access something that won't work in anything else, if you're using classic sites, and older software. Heck, if you're running Windows 7 or 8, you're using legacy software. If you're an IT professional that's been around for any length of time, if you think hard enough, you have or had recent experience with something "legacy". Again, moving from legacy software is something that needs to be done carefully and often over time. We depend on these "sunset" dates for planning purposes. And the new stuff? I can tell you that even in "Flow" or what's called Power Automate, they've already "depreciated" things without any notice at all. So it's not the age of the tool, it's the principal of saying you're going to support something until 2026, and then gutting it six years early and expecting everyone to be happy about it.

[Timothy Balk]

Wow... this is going to be a huge undertaking for our 3-person team to get done.

DON'T PANIC

[Steven Andrews]

The lead time on this is rather short.  Running the tool will hopefully provide some suggestions on upgrades.  I do find the depth of Power Automate to be somewhat lacking when it comes to SharePoint actions.

[Martin Cox]

Both PowerAutomate and SPD 2013 workflows lack the ability to change the permissions on a SharePoint list item. Only SPD 2010 workflow has this ability. This is a critical step in many workflows. Scenario: the initiator of the workflow fills in a form and submits the request. Once the request has gone into review by other people, that initiator must not be permitted to make any changes to that request. We use SPD 2010 workflow to change the permissions on the item after the initial user has submitted it. PowerAutomate had better well have this capability a couple of months before SP 2010 workflows stop working, or we'll be unable to perform mission-critical business automation in a secure way.

[Pieter Veenstra]

If custom permissions on list items is the only reason to keep SharePoint Designer workflows then why not use the SharePoint REST API in Power Automate to do the same.

https://docs.microsoft.com/en-us/sharepoint/dev/sp-add-ins/set-custom-permissions-on-a-list-by-using...

What are the use cases that you need to have working and I will have a look at creating a blog post on how to get this done.

How about:

Add a user to a list item

Break inheritance

Remove a user from a list item

[Sander_Del]

I understand PA is the way to go.

But, we need more time!!!

We have 50+ 2010 workflows managing permissions. Some of them are quite complex.

It is impossible to manually migrate all of them to PA before november 1st...

[John Mannion]

@Pieter Veenstra - circular approval processes with dynamic assignees and change-request functionality are one of the big reasons we still use SP2010 workflow over Power Automate.

[Pieter Veenstra]

@John Mannion dynamic approvals are not too complicated. I have done those with about 12 levels of approval. What does the change request bit mean? Do you mean change requestvitems that need the approval process?

[Denis Molodtsov]

Vote to postpone the retirement of the Workflow 2010 engine to a more reasonable date: https://lnkd.in/ePBDVgG.

P.S.  The title of the suggestion has a spelling mistake, but I can't change it. 

[John Mannion]

@Pieter Veenstra dynamic is not hard. Circular is not hard. But both at once? Essentially, the business needs approval sequences like:

1. Person A
2. Person B
3. Person C
4. Person A

Those assignments need to be made at run time (dynamic) and not pre-baked. I can't think of a way to do it in Flow without unnecessary heroics or "clunkiness" for the users.

As far as Change Requests, that is a standard feature in SP2010 workflow approval processes. Each approver can Approve | Reject | Request Change | Reassign. The built-in approvals within power platform only handle Approve | Reject the last time I checked.

[Mario-Longhi]

This decision is long overdue, but there is very little lead time.

Back in 2019, we went through a significant SP2010 to SPO migration (+2TB, 300 Site Collections) and had A LOT OF STRUGGLES with approval workflows.

After investigating the Power Automate platform, we decided to push through the migration and work out the SP2010 workflows since the PA tool lacked the robustness we needed. The tool is still very rough and cannot handle even simple workloads.

Removing SP2010 WF without a robust/real replacement will only push users to the SP2013 workflow. The same discussion will be had when that decision is taken for the SP2013 WF.

I appreciate that the statement and decision is made. We need this to push our end-users and business to take action. But we definitely need more time for the change.

[Martin Cox]

@Pieter Veenstra To answer your question what are the use cases, I think I spelled it out in my post: Scenario: the initiator of the workflow fills in a form and submits the request. Once the request has gone into review by other people, that initiator must not be permitted to make any changes to that request. Note: this requires item-level permissions, not just setting custom permissions on a list. Yes we would appreciate a blog post about how -- through the REST API and Power Automate -- to break inheritance of a single list item and custom set the permissions of that one item.

[Jack Willis]

4months???! What are you guys smoking over there at Redmond these day?

[Warwick Ward]

We all agree PowerAutomate is the way forward and has really only been a real option to directly replace SPD workflows in the past 2 years maybe, but we have been building and deploying SPD workflows for what 6-7 years now, and we get a few months notice before they don't run completely... 

The message from Microsoft before this was encouragement to use Flow yes, but SPD workflow aren't going anywhere soon so don't worry... ummm ok.

[Dahai Fang]

Lucky I only have 161 SP2010 workflows to support, and 187 SP2013 workflows.

This is crazy!!!

Please, give us back the 2026 support promise!

[ddaviscomsec]

I implore Microsoft to at least keep existing Sharepoint  2010 workflows active. In my opinion, power automate does not easily offer what the simple out of the box SharePoint 2010 Approval workflow does.  For instance, with the 2010 workflow, there is a complete audit trail providing details such as when the approval email was sent out and when the user actually approved. Not to mention the easy on the fly sequential approval process. Rebuilding these features in Power Automate, if even possible, is going to be a tedious and painful process. Unless Microsoft's intention is to cause it's customers pain then I believe a 2026 deadline is more appropriate. This is the 2nd or 3rd time within the last few months that sudden cloud upgrades have threatened to cause us undue pain. I am beginning to realize ever so slowly that the cloud is definitely not appropriate for all scenarios especially when you lose the control and stability that on-premise options provide. 

I would ask Microsoft to reconsider this decision and at the very least grant an extension to 2026.

[ASampedro]

Question about on-premises Sharepoint 2013 server.

Will Sharepoint 2010 workflows continue to be supported for on-premises Sharepoint 2013 server after August 2020? It is not clear from this article. 

[Ian_Morrish]

I wish I had thought of this on April 1st, would have been the best April Fools day joke.

Expect the corporate backlash on this to be soo great that MS will capitulate (here's hoping).

[Jack Willis]

I have written a support ticket to MS. I suggest anyone affected by this do the same. 4 months isnt enough and MS need to hear the customer voice - small or large, without this nothing will change. I seem to be on the phone to my developers every 3 months complaining about some forced change, functionality change which has been done without proper notification in-line with the life cycle policy

"sharepoint 2010 workflows. I received notification last night that we need to switch all our running/fine 2010 workflows to flow. 4 months is not enough to do this and I am sure you are hearing the same from many others. In 4 month we may be able to move some to 2013, but not flow.....please five us a bit more time. 12 months."

[Tony Hignett]

Out of the box approval workflows may deployed as part of a site or list template and execute as system account.

How do you achieve this in Power Automate?

How do you ensure that when a new list is created from a List Template, the approval workflow is applied to that list?

How do you deploy a simple approval workflows to multiple lists within a site as part of a Site Template?

How do you configure Power Automate for a Content Type?

[PPapasotiriou]

Microsoft are you crazy people?

2013 flow is missing the classic approval task, feedback task etc.

Power automate flow has an as premium task the http action etc.

How can we migrate?

Please postpone the date after you solve all the missing actions

[IvanCole-dxcecl]

There does not seem to be a way to turn on PowerAutomate workflows with a classic calendar list.  How can we enable these on classic calendar sites.  I don't think you can disable SharePoint workflows until there is a path to accomplish the same using PowerAutomate.  Also can you confirm that with the integration of SharePoint and PowerAutomate the list entries on an email approval will not be accepted without the Approval completing successfully?

Thanks

Ivan

[dbro_2105]

I could spend the next four months re-working just one finance solution.  How am i going to possibly do the other 15 in our environment still using 2010 style workflows.  This includes OOTB approval, 3 state workflows etc?

[Kevin Dolby]

This is unbelievable Microsoft… So in the middle of a pandemic where IT admins are already stretched thin with various other tasks, you decide that it is a good time to give everyone 4 months to completely re-architect and setup workflows across their entire tenant… Some of those workflows took months to plan, create, and test alone… On top of that, your solution going forward doesn’t even cover all the needs that were possible in 2010 workflows (see various examples in comments above)!
 
I would say this is a joke but it’s not funny, this decision is going to cause severe disruptions in business processes which are critical during the pandemic for companies that are doing critical work for the nation. I can see I am not the only one that is shocked and scared about this decision. What happened to the support until 2026? What happened to common sense and respect for your customers?

I strongly suggest you extend the deadline and I would also ask that you keep existing workflows active and just remove the ability for new 2010 workflows when the final date comes. I cannot understand any rationale behind this decision and timing, whoever made and approved this decision should be ashamed of themselves to consider this logical and feasible.

[Chris McNulty]

@ASampedro yes, the 2026 EOS date previously stated for on premises SP2016/19 servers (only) remains as is.   

[Jack Willis]

Appears that cloud customers are the second class citizens. MS can't treat their platform like a tin pot dictatorship -businesses require time to plan if trust is to be maintained and inward investment is to continue. Each of these decisions is eroding trust. We have started our migration process to flow, as many have stated the transition is complicated by needing to create rest APIs etc to recreate what was done before (simply and for v low cost). I can only assume this 4 month notice period was used to shock the user population into action, this has worked, please give us the real time frame now. Thanks, Jack

[Robyn Cranor]

There is a cost to using Power Automate that isn't there with SharePoint Designer as well. 

[jakenovak]

The biggest reason our organization hasn't adopted Power Automate yet is due to its lack of features, and general unreliability.  Flows don't run like Workflows did; they sometimes don't run at all, for seemingly no reason.  Workflows (especially 2010), for all their shortcomings, ran mostly flawless.

It's unfortunate that this is taking place.  For our applications that now need replacing, I don't believe I will be suggesting any Microsoft products to take up the task due to this incident.  Our organization simply cannot run our applications on unstable and unfinished products, just to have to transition in a few years' time because of a new "latest and greatest" approach at MS.

[Timothy Balk]

@Chris McNulty - I think this would be a good time revisit some of the comments you left in this discussion: https://techcommunity.microsoft.com/t5/sharepoint/infopath-support-in-sharepoint-online/m-p/97876/hi...

This is definitely an announcement where it will catch a lot of people off guard especially those who are not paying attention to the MS Tech Community. Precedence has been to give more of a longer notice, but with the larger need of cloud services I would guess that 2010 and 2013 Designer workflows are causing a strain on infrastructure which could be better utilized to make services faster. Please consider giving the why's for this decision and timeline?

Also consider publishing an article elaborating on this comment in particular (in the thread linked above):

There is DIFFERENT governance for service removals in Office 365. The strict guidance is that Microsoft will give at least 30 days notice when we've indiciated a replacement product; 365 days notice if there is no replacement; and that undocumented, unsupported features or risks which are found to compromise the security or platform integrity could be turned off immediately.  For example, if we found a huge security loophole in the "Widget" web part, for example, we might remove that web part immediately to protect our customers while we work on the issue. 

It's scary to think about this as well... I have a hunch that we may even see an announcement regarding InfoPath 2013 EOL soon in SharePoint Online. Our team is scrambling to figure out what we need to license and what we need to do. A 6-9 month timeline would make us feel better about taking these changes on. More time to plan, more time to communicate, more time to implement.

[pwcaldwell]

@IvanCole-dxcecl   I have been able to have Power Automate run on a classic calendar.  In my case, it runs when a new calendar item is added.  We use it for time off requests. 

@Chris McNulty  I figured this day would come when I first started using Designer back in 2013 so avoided making any 2010 workflows.  That said, there is one thing I wish Power Automate (and 2013 workflows for that matter) had -- the ability to Declare a list item ( List specifically not to be confused with a document library item) a record.  I can do it in 2010 easily without having to resort to breaking inheritance and changing the permissions.  While saying what I'd like in PA. is the ability to MOVE a LIST item to another list.  Moving it means moving the version history as well.  Just adding to another list does not help when I need the version history.  That leaves me to have to manually use Content and Structure to move list items which I'm always afraid is another thing that will get retired with no replacement.

[Jeff Genovese]

Custom permissions are the big thing that I need 2010 Workflows for.

I have a SharePoint list for employee evaluations. The manager chooses the employee using a people picker field and fills out the rest of the evaluation. Once it's saved, the workflow kicks off breaking the inheritance and giving read-only permissions to the manager/author and the employee selected. HR is given full access to all items. 

There's another list for something similar, where the author chooses multiple people in a people column and each of them get access to the list item. 

If there were a set of instructions for using Power Automate with SharePoint REST API to achieve the same results, I'd love to see it.

[IvanCole-dxcecl]

To be clear there are no embedded menus that integrate to a classic calendar site correct?  Is there a way to convert it to get the native experience?

[Chris McNulty]

Thanks @Timothy Balk - yes our comments in 2017 are still relevant here.  We think gong beyond the 30 day notice for modern lifecycle products like M365 was important to do here, and we can offer additional support through our official support channels as needed.

[Chris McNulty]

@Jeff Genovese there's some guidance online about using the SharePoint HTTP action (NOT premium) to set permissions: https://collab365.community/sharepoint-item-permissions-using-flow-part-1/

[GilesGregg1135]

What does depreciated mean? "SharePoint 2013 workflows will remain supported, although deprecated"

[Marcus_Khoo]

@Chris McNulty 

Most of the comments here are based on the actual functionality of SP2010 workflows - which as far as I can see is not fully duplicated in PA for Sharepoint permissions in the same manner as a SP2010 workflow.

Even if the functionality were duplicated - what about the UI for existing "classic" applications?

Many apps use the "Classic mode" Ribbon to trigger 2010 workflows. 

As an example:

Imagine a FOUR or more level approval cycle

• A user creates an item "DRAFT" and saves it. 
• On save the draft changes security so that only that user can see the item (all approvers are unaware of the item)
• When viewing the item, the "EDIT" and "SEND TO" ribbon buttons are visible in their ribbon.
• When they are ready they click the "SEND TO" button on the ribbon and the item goes to the first level approver.  A 2010 workflow triggers and changes permissions on the item.
• The item is locked from editing by the original creator 
• If the original CREATOR looks at the item then they see no ribbon actions.
• If the first level approver looks at the item they see "EDIT", "REJECT" and  "APPROVE AND SEND ON" buttons.  At this point the second level approver is totally unaware of anything so will not even see the item.

Just an example - but all the users are familiar with triggering workflows from buttons in the ribbon. 

What impact will forcing PA have on the existing UI's?

[Phil Silvio]

This timeline is not acceptable for the real world.  I have often said that Microsoft lives in it's own world.  WIth everything going on in the business world right now, how do they expect enterprises to get all workflows re-done in less than 4 months.  We are in the middle of migrating from SP2013 to SPO to get off old servers and technology.  Due to time and resource constraints we made the decision to migrate workflows as-is then spend 2021 rewriting them using PowerAutomate.  I understand removing old technology, but you HAVE TO give your customers more time to get things in line.  This timeline needs to be extended and give at least a year warning.  I put in a service ticket about this as someone suggested, they just called me and said "nothing we can do".  I'm also going to escalate this to our account rep.  We have to make sure Microsoft hears from people on this one to extend it.

Also, vote for the extension here:  https://sharepoint.uservoice.com/forums/330318-sharepoint-administration/suggestions/40856713-postop...

[sickaroll]

This is an astonishingly myopic and damaging change, and with little to no notice, and a slap in the face to the dozens of client's we've convinced to migrate off on-premises into the Microsoft Cloud.
I have 50-100 clients with between dozens and hundreds of critical workflows each using the 2010 Foundation.

It's still far and away the easiest, quickest method of setting an object's permissions programmatically based on metadata.

Quite aside from my team's current project load, we now have 115 days to re-engineer thousands of workflows in PowerAutomate or Logic Apps?

Simply not viable, we'd need closer to 2 years to gear up for this, even with additional hiring. 

Consider this real, edge-case scenerio; we've recently deployed a little over 7,000 lists from a template for a big client, recently migrated to SPO. Each with a 2010 metadata tagging workflow.
Recreating this in LogicApps will require 10 connections and 10 actions, for an instance run cost of €0.00128, which seems reasonable.
However, as we can no longer trust that 2013 workflow won't be disabled with 3 months' notice, we can't have a 2013 WF HTTP request a LogicApp and because LogicApps/PowerAutomate do not have true Triggers or fire on Event Receivers, checking those lists every 2 minutes for changes would require 1.8 billion annual runs. 
In a worst case scenario he annual Opex cost of thus one workflow solution would go from €0 to €2.3 million overnight!
That would be if I had time to do the remediation, which I don't, so they'll just fail.
Thanks a million guys.

[Marcus_Khoo]

I bet some customers using SharePoint online and 2010 workflows are not even aware of this announcement because they are so busy keeping things together in lock down.  @Chris McNulty Expect some VERY upset customers ranting at Microsoft later this year.  

[Cheryl Banke]

Does anyone know if this change away from workflows will affect the Content Organizer Rules?  We automatically route documents from a drop-off-library to a standard library with these rules.  If it does, we have some work to do...  

[Scott1370]

OMG, I see a huge push back on this one!!!!!!    And such short notice.  We will need at least a year to convert our 350+ 2010 workflows.   

[John Guilbert]

Hi Chris,

You are joking of course. This will have ramifications for Microsoft if they go ahead with it - that date is not realistic for businesses that use SharePoint seriously - clients will look unfavorably at Microsoft's approach here. About 90% of our SharePoint clients are using 2010/2013 Workflows and are trying to get them onto Azure to use Logic Apps. We are gently guiding your loyal customers how to move to Azure, but you are using heavy handed tactics.   

I think you need to reconsider the date. Costs to our businesses will be majorly ramped up.

Thanks.

John. 

[DJTrustGod]

I'd urge that Microsoft consider a date in 2021 for this retirement. While it's great to get rid of legacy workflows and fully move to Power Automate, dropping this arbitrary short-notice deadline while business and projects are still in recovery mode from Covid-19 is not good.

We’ve been using Power Automate Flows for all workflow projects since 2017, and we are big advocates of the Power Platform.

But since we've moved many on-premises farms to SharePoint Online, there are just a large amount of legacy workflows we'll need to work through.

[Chris McNulty]

@GilesGregg1135 SharePoint Designer and its workflows are deprecated.  A deprecated feature is no longer being invested in by Microsoft and we discourage customers from taking a dependency on it if they haven't used it before.   It remains governed by our support lifecycle policies.

[techcat302]

Totally not cool, especially when Microsoft has said at every recent SharePoint conference I've attended that 2026 was the EOL date and not differentiated between support for SharePoint Server and M365 versions of SharePoint 2010 workflows. This is insufficient notification. This is super stressful during a time that is already very stressful. 

[sickaroll]

@Chris McNulty Saying that SharePoint Designer workflows are deprecated is reasonable, PowerAutomate and LogicApps can do almost all the things the existing workflow engines can do. However, they are not directly comparable, and there's an enormous difference between not adding new features to, improving and supporting something and disabling it entirely with next to no notice. 
It's hard to see this as anything other than a bare-faced money grab, and at a particularly callous time when many of your customers are already bleeding.

The old WF engines were essentially free to use with your license and the new methods are significantly more expensive to run. 

I'm not really all mad that you want more money, but I'm livid that you think it's ok to disable a feature that is widely used on 3 months' notice. Microsoft (and perhaps even you personally?) promised at Ignite 2019 to support the traditional workflow engines until at least 2023.  It's simply not enough time for already stretched IT departments and consultancy practices to replace all of them. We will get our customers on the new platforms, but it's not that long since the new stuff became a viable replacement; customers and consultants need more time.

I sincerely hope you reconsider at least the timeline, because if not, it's frankly one of the more despicable things Microsoft has done to it's customers in recent times. 

[Jeff ANGAMA]

:rocket: :rocket: ☁ ☁ I agree on the move. I disagree on the given timeline to customers. 

Companies are just out of covid19 epidemic shock, deploying teams urgently, facing economical plan, firing people, go for summer holiday and Microsoft announce in july to rewrite workflows in 5 months. 🤷‍ 

Please vote !  :speaker_high_volume: :speaker_high_volume: :speaker_high_volume:

https://sharepoint.uservoice.com/forums/330318-sharepoint-administration/suggestions/40856713-postop...