Menu
Free Pack
Download BuildMaster Free Trial

Windows Workflow Foundation: Time to Move On?

by The Inedo Team, on Jan 8, 2021 3:31:49 PM

Just like WCF and Web Forms, Windows Workflow Foundation (WF) is not part of .NET 5. That does not mean that Microsoft killed it though. Windows Workflow Foundation's support period should go beyond the support periods for .NET 5, .NET 6, and even .NET 8.

But should businesses continue using Windows Workflow Foundation (WF)? Now is an excellent time to consider why you use WF in the first place and decide if it is still the best solution for your organization.

dotnet5_workflowfoundation

In this article, we will answer the questions:

What is Happening with Workflow Foundation?

WF is not dying any time soon. WF is part of .NET Framework and will receive support for as long as .NET Framework is part of the Windows Operating System. While WF will not get any new features or innovation, it will continue to get security updates and bug fixes for a long time. (More information is available on the Lifecycle FAQ for .NET Framework.)

Your team can safely plan to use WF applications for the long-term but should not target WF for new applications. WF is now a legacy technology, and that comes with some complications:

  • It will be harder to find developers. Given a choice, most developers want to work with newer technologies and learn skills they can apply to many different opportunities, not legacy applications.
  • Legacy applications increase in cost over time. The longer you stay on WF, the more expensive changing or migrating becomes. For one thing, finding talent to maintain your WF apps will be difficult and costly. For another, even with less experienced developers who learn WF as they go, it will take more time and incur more risk to make changes.
  • When support ends, security will be a significant issue. WF is going to be supported for a long time but not forever. Once support ends, exposed vulnerabilities will require you to migrate quickly or find a way to patch the issue yourself.
  • WF makes the whole application legacy, not just a component. WF is designed to work with .NET Framework technologies like WCF. Keeping WF locks you into using additional legacy components for your whole application.

These trade-offs may be worth it, and you may have already experienced them. WF has not had a feature update from Microsoft since 2017. It has continued to work this whole time and will continue to work for the long-term.

But just because WF will work doesn’t mean you should use it. Depending on why your team uses it, there may be a better solution available. The release of .NET 5 marks a great time to figure out what problems WF solves for your organization and investigate whether it’s still the best solution.

What Problems Do Teams Use WF to Solve?

There are three main problems companies use WF to solve:

  1. Combine business actions flexibly: WF allows you to combine multiple processes into one larger one. Better yet, WF makes sure your processes follow a specific order and lets you change that order easily.
  2. Long-running processes: WF allows operations to run over a very long period without holding any hardware hostage. It stores the state of each process in a database instead of the system’s memory. This way, systems can prioritize active processes and continue an incomplete process months later.
  3. Allow non-developers to change applications: WF is a .NET technology uniquely approachable for non-developers. The Workflow Designer allows business processes to be organized and built with a GUI tool.

But not every team using WF values these three solutions equally. WF is a decent way to solve all three problems, but it’s not the best solution for each individually.

  1. The flexibility ends with the order of actions. Microsoft made WF for .NET Framework technologies exclusively. Sometimes a .NET Framework technology is not the best choice, and developers may want to use something else.
  2. Processes on WF still require more resources than other solutions. .NET Framework is not as memory efficient as .NET 5 and other technologies. Other frameworks can allow for long-running processes with better performance than WF.
  3. WF is still complicated for non-developers. While WF has a GUI interface for creating components and workflows, it still requires users to be familiar with Visual Studio, XAML, debugging applications, and other development concepts. You need developers to keep the WF program running fully.

WF is powerful but flawed. It is a solution for all these problems, but not a perfect solution for any of them. If you find yourself frustrated with WF's limitations in any one of these categories, it is worth considering some of the available alternatives.

What are Alternatives to WF?

Keep a Workflow, Find a New Framework

How flexible is it? Can it support long-running processes? Can non-developers build with it? What are the migration costs? What are some potential risks?
⚠️ Flexibility depends on the framework. ⚠️ Possibly. Depends on the framework.  Yes. In almost all cases, there is a workflow chart accessible to non-developers. ⚠️ Depends on the framework. Some require direct monetary investment. ⚠️ Migration can be difficult. Framework may lose support in the future.


Many businesses want to move ahead with newer technology but require the structure of a workflow. In these cases, consider using a different framework.

There are other workflow frameworks for .NET besides WF, like Netflix’s Conductor and Workflow Engine. There’s no “best” workflow framework, because the best solution will differ for each business. When looking for a replacement, consider what WF does for your business in the first place:

  • Is WF primarily used by the developers to simplify application changes? In this scenario, a framework like Conductor would work best. With Conductor, developers can build each component with almost any technology. They can continue to use .NET technologies to create the application or branch out into other solutions when necessary.
  • Is WF used for developers and non-developers to contribute to an application equally? In this scenario, a framework like Workflow Engine would work best. It allows developers to make components with .NET while providing a browser-accessible GUI workflow. While this is less flexible for developers than Conductor, it is more accessible for non-developers.

A new framework is the best solution for teams that like workflows, want to use modern technologies, and require both developers and non-developers have direct control over the application.

Take action: Organizations interested in a new framework should start the migration by following these steps:

  1. Research and evaluate different frameworks based on how well they address your organization’s needs.
  2. If possible, test appropriate frameworks. Get a sense of how the team feels about them and how difficult the migration will be.
  3. Review team impressions and potential migration difficulties with stakeholders to determine if a new framework is worth the effort.

Adopt a Low-code or No-code Framework

How flexible is it? Can it support long-running processes? Can non-developers build with it? What are the migration costs? What are some potential risks?
Least flexible. Designed to use pre-built components. ⚠️ Possibly. Depends on the No-/Low-code framework.  Yes. That's what these solutions are made for! Almost all require direct monetary investment. Required to recreate application with no-code components. ⚠️ Migration is difficult. Framework may lose support in future. Pre-made code may not meet all requirements.


Low-code and no-code frameworks are like traditional workflow frameworks but designed to use pre-made components instead of custom coded components. Kissflow and Decisions are examples of frameworks designed with non-developers in mind. In theory, low-code and no-code frameworks allow for non-developers to build complete applications. But keep these points in mind when considering this solution:

  • Expectations may need to be adjusted when using a low-code or no-code framework as the pre-made components leave a lot less room for customization. Think of it as a fast-food burger: I can ask for pickles and onions, but I don't get to decide which brand of pickles to use or the exact number of onion slices. It’s easier than making it yourself but might be a lot less satisfying depending on your tastes.
  • Many low-code and no-code frameworks can integrate with other applications, ranging from Google Workspace to custom applications. But the more integrations needed, the more complex the application will become. If you need to integrate with a custom application, you may need some developers to perform the integration or provide ongoing support.

This solution works best for companies without many custom requirements and that need non-developers to control the whole application. These solutions are great for empowering non-developers to make simple applications. But don’t expect them to perform like custom solutions. If your business doesn’t fit both of those criteria, it may be best to consider alternatives.

Take action:Organizations interested in using a low-code or no-code framework should start by following these steps:

  1. Discuss trade-offs with team and stakeholders to decide if a low-code or no-code framework would be a good fit.
  2. Research available frameworks and narrow down your options.
  3. Discuss the capabilities of selected frameworks with vendors and determine which one best addresses the organization’s needs.
  4. If possible, demo the framework yourself to assess usability.

Wait for CoreWF

How flexible is it? Can it support long-running processes? Can non-developers build with it? What are the migration costs? What are some potential risks?
⚠️ Depends on how well it works with other .NET 5+ frameworks. ⚠️ Possibly. There are no guarantees, but it should be able to do as well as WF. No. GUI workflow designer is not included.  Least costly of all options. No direct monetary investment required. CoreWF may never be production-ready. Problems associated with legacy software while waiting.


WF may meet all your business’s requirements, and there's no need to move to the new .NET any time soon. If that’s the case, you can continue using WF while watching the development of
CoreWF. CoreWF is a community, open-source runtime of WF spearheaded by the .NET Foundation. But CoreWF has some potential issues:

  • Currently, it is considered “experimental” and not ready for use in production situations. But, as it developed further, that could change. Throughout 2020, the project has received consistent activity, and it looks like that will continue.
  • The project states that “the [GUI] designer experience is not part of CoreWF.” While you can port over the XAML code made with the GUI designer from WF, that is probably not enough of a consolation for teams that consistently use the GUI interface.

WF still works. If you have no reason to stop using it, your business can revisit this issue in a few years when CoreWF is further in development. If the time comes where you need to move to .NET 5 + and CoreWF is still not ready, you can always move to any of the other alternatives. We do not recommend planning to target CoreWF, as it may never be production ready. But there is no reason not to keep an eye on it.

Take action: If you think waiting is the best option for your team, follow these steps to make sure everyone’s on board:

  1. Discuss the advantages and disadvantages of delaying migration from WF with stakeholders and review if it is the best plan.
  2. Schedule a with stakeholders to discuss if WF is still the best current solution and reconsider migration.

Don't Use a Workflow Framework; Use Microservices

How flexible is it? Can it support long-running processes? Can non-developers build with it? What are the migration costs? What are some potential risks?
Most flexible alternative to WF. Yes, if you build in support. No. This is a development strategy, not a framework. ⚠️ Time is the main cost. May require direct monetary investment if new tools are required. ⚠️ Migration can be difficult. Non-developers lose direct control over the application.


“No Workflow Framework at all” may seem like a backward suggestion. But many businesses already make large applications made up of small parts arranged in a flexible order without a workflow. They do it by using microservices.

Microservices development is when you break down your application into discreet services and develop each independently. It's the same strategy as WF: you make each business action a service, then combine them into one process. Keep these things in mind when considering microservices:

  • Microservices are not tied to specific technologies. Unlike WF, microservices can be built with any technology or framework. You can use .NET 5 +, .NET Core, or even Java if you want.
  • Microservices give you more control over how you connect each service compared to a workflow framework. You can pick gRPC, ASP.NET Core, or dozens of other frameworks and APIs that better fit your exact problem than WF with WCF.
  • The structural flexibility of a workflow framework is possible with microservices. You can make applications with long running processes that can be changed when needed because each service is small enough to be changed quickly.

If you don’t have the developers needed, though, this is the wrong choice. By taking away the workflow framework, you take away the ability for non-developers to make changes on their own. If that is something your business needs, the other alternatives are better fits.

Take action: Organizations interested in replacing WF with microservices should follow these steps:

  1. Discuss with developers the pros and cons of removing a workflow from the development process and determine whether this option is worth pursuing.
  2. Do further research on microservices and get a sense of how your organization would like to build the project.
  3. Prototype a small portion of your application based on previous research and compare results to expectations.
  4. Discuss with stakeholders the results of the prototype and develop an official migration plan.

The Take-away: You Have Time to Decide

The good news about WF is that it is not going anywhere. There is plenty of time to decide if it is the best solution for your problems and whether any alternatives would work better.

  • WF is an adequate solution for many problems but not a complete solution for any individual problem.
  • Other Workflow Frameworks exist that may meet your specific needs better. Whether that’s a newer framework, a low-code framework, or waiting for CoreWF depends on the team.
  • For many teams, a workflow framework may not make the most sense. Building your application outside of a workflow as microservices allows you to pick the best solution for each job.

As we’ve said throughout our .NET 5 series, the most important thing for your organization is to begin the conversation about aging technologies. Starting the planning process now saves you from the risks of hasty decision-making later.

We’ve built a guide to help you successfully navigate the migration to .NET 5 and beyond. Get your copy today!

Topics:.NET 5Workflow Foundation

More...