Sitecore Upgrade – WFFM to Experience Forms

Posted on


Sitecore Webform for Marketers (WFFM) has always been on the dark side of the CMS and maybe a nightmare during a Sitecore upgrade. Many developers avoided it as they find the entire approach redundant and they rather create the form from scratch and benefit the freedom that comes with it. On the other hand were the developers who have mastered the workflow and started creating forms seamlessly. They made the client happy with their short estimations and highly configurable solutions. Marketers also loved the fact that they could modify the form on their own. They also learned to deal with the technical limitation. During this never-ending dispute, Sitecore came in and render the entire thing obsolete and called it off from Sitecore 9.1. Isn’t it perfect? It was supposed to end the debate but instead it promoted us to the debate A league.

The Challenge

To put it short, New Sitecore form is nothing like WFFM and Sitecore has absolutely no migration guide.  All the WFFM forms should be converted into the equivalent version in Forms. Some kind hearted people have developed a tool to speed up the manual migration process which basically involves looking at the old form in one monitor and creating a new Forms in the other (that is only if you have two monitors, otherwise alt+tab is the way to go). Sitecore support does not recommend using the tool as if anything goes wrong during the migration, it will make theirs and your life difficult to figure what went wrong. We have used the tool and I can say it works for Simple forms using Simple field types. However, if you have custom field types and done some tricks in WFFM, this will not work.

The more sophisticated your WFFM forms are, the more complicated will be the migration process. All the custom fields and Save Actions must be converted to the equivalent one in Forms. This is not limited to customization but some of the OOTB WFFM Save Actions are also not shipped with Sitecore Forms and will never be. The image below illustrates the gap.

Field validations, parametrized save actions, form parameters, and all the other missing equivalent functionalities makes the form conversion the biggest challenge of a Sitecore upgrade.

How to estimate the effort?

If the content editor team are expert WFFM form designers and they create forms dynamically, this is great. Dev team can leave the job to them to recreate the forms and all you must do is analyze what they have been using so far and provide them a guideline on how to do the same on xForms.

You might think, the new forms save action is just a new class where you can copy the old save action code into and get the same logic working. The truth is many approaches that was used in the save action is no more supported in the new form save actions. For example, in the old forms, you could make the field names dynamic and pass the name through the save action configuration as described in this article. However, in Sitecore Experience Forms, it is not as easily available. For Forms, you must create Action Editor Item which has much higher abilities but not as easily available. Moreover, default values or prefilled forms are also not available out of the box but Sitecore has been kind enough to provide a good documentation for it. Look out for these pitfalls while estimating the upgrades effort.

Don’t forget the validations and Field types. Those too could be quite different to migrate and custom validations or fields must be estimated.


Sitecore Forms is the result of years of experience and feedbacks from WFFM users. I am very happy to see the end of WFFM as it was not made specifically for developers nor for the content editors. Now, xForms has the good distinction between developer’s workspace and the content editors. Despite all that the question remains; “Should we go with xForms or go custom?”

Leave a Reply

Your email address will not be published. Required fields are marked *