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

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.

In this article, we will answer the questions:

• What is happening with WF?
• What problems does WF solve?
• What are alternatives to WF?
• What about CoreWF?

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 innovations, 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 .NET5+ 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 individual.

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 .NET5+ 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

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 to 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

Low-code and no-code frameworks are like traditional workflow frameworks but are 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 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 the 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.

Don’t Use a Workflow Framework; Use Microservices

“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 .NET5+, .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.

What About CoreWF?

Another option you may have come across is CoreWF. Much like CoreWCF, it was developed with the intention of being a stop-gap, bringing WF to .NET5+. It is being developed/maintained by UiPathwho currently use it internally for their workflow products

Is it worth using in .NET5+?

Unfortunately, it’s a no from us. CoreWF receives minimal development. Updates are few and far between with an evident lack of any roadmap for future development. Unlike CoreWCF, it hasn’t gained enough traction to be supported by MS and is not a simple drop-in replacement. It would take significant efforts to migrate applications from WF to CoreWF.

Additionally, CoreWF is missing GUI Designer. This is a key WF feature that enables users to create their own workflows. It’s absence has been a clear point of frustration for developers.

There is some compatibility with Workflows created by WWF and WWF’s .NET Framework-based UI, but with no comparison matrix, it’s hard to tell what features are not supported.

It’s clear it will never be a compatible replacement for WF in .NET5+. As a potential option, it exists and might work given enough time and effort, but there are much better alternatives.

The Takeaway: 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 or a low-code framework depends on the team.
• The one exception to this is CoreWF. It’s a possible choice but far too weak of an option compared to the other alternatives.
• 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 .NET5+ 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 8 and beyond. Get your copy today!