This article is part of a series on Migrating from .NET Framework to .NET, also available as a chapter in our free, downloadable eBook

Windows Workflow Foundation, aka WF, is no longer supported in the current .NET. While it isn’t dead, it certainly isn’t thriving.

WF is tied to .NET Framework, which in turn is tied to the Operating System. WF will last until its Framework reaches the end of its life; so it’ll continue to receive security updates and occasional bug fixes, but it won’t get any new features.

For those looking to plan long-term and post-workflow, we’ve compiled four alternatives to using WF that will keep your operations running smoothly after switching.

1. Keep a Workflow, Find a New Framework

Simple and straightforward, keep your workflow but use a new framework that still operates with .NET, like Netflix’s Conductor or Workflow Engine.

When switching, consider why you have workflows, to begin with. Is your WF used to simplify application changes or contribute to an application equally?

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.

2. Adopt a Low-code or No-code Framework

Designed like traditional workflow frameworks, no or low-code frameworks use pre-made components instead of custom-coded components. Kissflow and Decisions are good examples designed for non-developers.

This is an ideal alternative for organizations that don’t have many custom requirements, creating a low barrier of entry for making simple applications. Clearly, however, since it doesn’t have custom requirements it can be inflexible and will require direct monetary investment to recreate an application with no-code components.

3. Wait for CoreWF

CoreWF is a community, open-source runtime of WF that will be the least costly for migration, but it has its other issues. CoreWF is considered “experimental” and not ready for use in production settings. It doesn’t have a GUI designer experience, which will greatly affect teams who consistently used the GUI interface.

To reiterate, WF is still functional until approximately 2030. If you’re likely to use WF for a long time, you can come back to CoreWF in the future and see if the wrinkles have been ironed out. We don’t recommend planning to target CoreWF, but there’s no reason to not keep an eye on it.

4. Don’t Use a Workflow Framework; Use Microservices

The most flexible alternative to WF, microservice development is great for breaking down your application into distinct services and developing each independently. It’s just like WF: you make each business action a service, then combine them into one process.

There are three big benefits to switching to microservices: flexibility (as mentioned), microservices are not tied to specific technologies, and you have more control over connections compared to a workflow framework.

This is a great choice for a team of developers, but microservices will take away a non-developers ability to make changes independently.

Tied to Framework, but not tied down

Windows Workflow Foundation is certainly past its prime, but it’s not down for the count. It will last as long as .NET Framework / Operating System is still supported. That said, the end is on the horizon, so it’s worth considering a plan for retiring your Windows Workflow Foundations.

Although .NET Framework 3.5 and 4.8 are estimated to last another 10 years, it never hurts to start planning for migration. Consider how you’ll move your package libraries; now may be the time to consider a CI/CD method.

Phew, that was a lot to digest, and you explore how to best replace WF in your organization, I suggest bookmarking this page on the alternatives to revisit later. Better yet, grab a copy of our .NET Migration Guide. It expands on what you’ve learned here, with further insights into transitioning to microservices, managing dependencies, integrating CI/CD workflows, and more. Download your free copy today!