Replacing Classic Workflows: Which Ones First?

Many grown solutions carry a stock of classic workflows. They were built when Power Automate did not exist yet. They run, and nobody likes to touch them. When a modernization comes up, the question follows: does all of this have to be rebuilt, and where do you start?

The short answer: not everything, and not right away. The long answer hinges on a distinction that gets lost in many discussions.

What Microsoft actually recommends

For years, Microsoft has said that new automations should be created as Power Automate flows instead of classic workflows. Existing background workflows should be reviewed, and replacing them with flows should be considered (Microsoft Learn: Replace classic Microsoft Dataverse workflows with flows). Microsoft has not named an end date for classic workflows.

That is a recommendation, not a shutdown. If you rebuild the whole stock in a panic, you spend money on something that could move along with the next functional change anyway. If you ignore the stock, you keep building on a technology that Microsoft no longer invests in.

Background or real-time: the key distinction

Classic workflows come in two variants. Background workflows run asynchronously. The user saves, keeps working, and the workflow follows shortly after. Real-time workflows run synchronously in the same transaction. The user waits until they finish, and they can even cancel the save with an error message.

For background workflows, Power Automate is the natural successor. A cloud flow with a Dataverse trigger also starts shortly after the change. It can do a lot that the classic workflow never could: loops, for example, or connectors to other systems.

That does not hold for real-time workflows. Power Automate does not run synchronously, as Microsoft's own comparison also says. So a flow cannot prevent a save, and it cannot set a value before the record is written. Microsoft advises checking whether the goal, or part of it, can be solved asynchronously. It also points out that synchronous workflows contribute considerably to performance problems. What really has to stay synchronous needs a different replacement:

• Plug-in: the classic way to run logic inside the transaction. It offers every possibility, with the drawback that it needs a developer and source code.
• Business rule with table scope: for simple field values and checks. It then also runs on the server and not only in the form.
• Low-code plug-in: logic in Power Fx that runs on data events of a table. Microsoft currently lists this feature as a preview that is not meant for production use (Microsoft Learn: Low-code plug-ins). So it is not yet a replacement for production.

Which ones first

A sensible order follows from effort and impact.

Inactive workflows and drafts. What does not run does not need to be migrated. Ask whether anyone would miss it, then delete it. This is the cheapest way to shrink the stock.

Real-time workflows with broad triggers. A synchronous workflow that starts on changes to many fields slows down every user on every save. The impact is largest here. A review often shows that most of the logic does not have to be synchronous. That part becomes a flow, and only the rest stays in the transaction.

Workflows with custom workflow activities. They contain compiled .NET code. Power Automate cannot call such activities. Whoever rebuilds them has to touch the code anyway, and should first clarify whether the source code is available.

Simple background workflows. Sending emails, setting field values, creating tasks or assigning records. They are technically easy to replace, but there is no time pressure. It makes sense to rebuild them when the related process changes anyway.

Which ones may stay

In some cases the classic workflow simply can do more for now. Microsoft's comparison names, for example, access to the state of the record before the change and wait conditions on columns. Power Automate has neither. A workflow that waits until a date is reached or a status is set can be rebuilt, but unfortunately not one to one. If you switch such workflows, you also have to clarify what happens to the workflow instances that are waiting right now.

A background workflow that has run without errors for years and is well described may stay as well. It goes on the list and gets replaced at the next revision. That is not negligence. It is a priority.

How to recognize the stock

For sorting, you need four details per workflow: background or real-time, trigger, status, and whether custom code is involved. All of this is in the solution export, and D365 Audit checks it.

How classic workflows fit into the rest of the list of outdated technologies is covered in What are outdated customizations?. The order of a larger modernization is in Upgrading old solutions.