Introduction

If you have come across a migration project to migrate from any SharePoint on-premise environment to SharePoint Online (Microsoft 365) and the customer uses Nintex for the forms and workflows, you will need to buy Nintex Licenses for SharePoint Online and migrate Nintex Forms and Workflows to SharePoint Online OR you can give it a try to migrating your forms to PowerApps to develop the forms and Power Automate to develop the workflows.

Points to be considered while you migrate from Nintex forms to PowerApps

1. Non-Technical

a. User experience changes: The Nintex forms in the on-prem environment are different than PowerApps forms, so there will be huge user experience change. Though PowerApps will provide a better user experience as it is
responsive and has modern user interface elements.

b. User Training: As user experience will change, the users would require training or a user guide.

c. Users who will use the forms, what license those users to have.

d. If users have an M365 license which covers PowerApps, then evaluate whether your application requires any functionalities which require any premium connectors

2. Technical

a. If your Nintex forms use repeating tables, the implementation of repeating tables in PowerApps will be different and will have a little learning curve for the developer who develops the PowerApps.

b. You can develop PowerApps User Interface mobile-friendly, so consider looking at options to do responsive design for PowerApps.

c. Opt for SharePoint List Forms/Canvas Apps/Model-Driven Apps depending on requirements.

d. Attachments: The attachments implementation will be different based on whether you need single attachment control or multiple attachment controls.

Points to be considered while you migrate from Nintex Workflows to Power Automate

1. Non-Technical

a. User experience changes: E.g. Nintex has approval tasks forms where Power Automate has approval within outlook or teams or approval from Power Automate.

b. User Training: Due to changes in how user interact with workflow steps, will require a little user training or user guide.

c. Users who will use the workflow, what license those users have

d. If users have an M365 license that covers Power Automate, then evaluate whether your workflow requires any functionalities which require the use of any premium connectors.

2. Technical

a. Workflow History: Power Automate does not save the workflow history as it used to work in your Nintex Workflows, so you need to write your own logic to save details to workflow history if you are looking for some audit information of the workflows. Flow does save the workflow instance for 30 days but then it won’t exist after 30 days so if you need audit information of your workflows then you can save it to the SharePoint list by adding some actions in your flow.

b. Approvals:

i. Nintex uses workflow tasks to implement approvals, Power Automate has its own approval actions which creates Approval within Power Automate which users can act upon from Power Automate Approvals section or outlook or Microsoft Teams. As another option, you can use adaptive cards to implement custom approvals which can be sent as email or message on Teams channel or user.

ii. Nintex workflow task also has built-in reminders functionality, which Power Automate does not have so you need to build Reminders functionality in your flows.

c. If your Nintex Workflow uses State Machine to manage different stages of the workflow, then State Machine actions does not directly exist in Power Automate, you will need to implement state machine equivalent logic using Do Until and Switch actions or develop multiple flows for each state and a parent flow which calls the flow depending on the stage of the workflow.

d. Consider the flow runs, as under M365 license 2000 flow runs/per user are allowed, so if it goes over your flows will start creating issues.

Some of the lessons we learned while migrating from Nintex on-prem to PowerApps and Power Automate.

1. PowerApps

a. As we had significant business logic on the form and a large form, we opted to use Canvas apps. Model-driven apps are not covered under the M365 license, so we did not go under that path. If you want to store data in the SharePoint list and have fairly large forms to be developed in PowerApps. If you have a very small form with little business logic, then you can do the custom PowerApps list forms for the SharePoint list.

b. If you want to implement repeating tables which takes input from users, and allows users to add multiple rows of data, then this implementation will be tricky, you will need to implement custom logic to store data as JSON in SharePoint list for storing repeating table data.

c. We had a Nintex form that used multiple attachment controls, the same is not available in PowerApps, so we used gallery controls and attachment controls to build multiple attachment sections in the PowerApps form, and stored the documents in the document library as also had metadata associated with the attachment.

d. To design the Canvas app, we used a separate branding screen from where UI elements like font color, font size, font family, button size, button colors, etc are configurable, this helps so that making change at one place applies to each element in the form, rather than changing the design values on each element every time.

e. M365 license doesn’t cover creating environments, but if you have a P1 or P2 plan, then it’s useful to create different environments for dev, test, and prod, for a better development lifecycle.

f. Use service accounts for connections, so that the user account of the user developing the app, is not used in the connections of the app. When users leave the organization, then the app will stop working if their account is used in connection, so it’s a good practice to use service accounts in connections used by the app.

2. Power Automate

a. Power Automate approval action can’t use SharePoint groups directly, so if you are using SharePoint groups, then you need to first query the members of the SharePoint group and then create approval for those members or use Office 365 Groups which can be used directly in the Power Automate approval actions.

b. Approval actions do not have reminder functionality so we build a separate flow that runs on a daily basis to determine on which workflow instances the reminder needs to be sent.

c. If you want to update data in SharePoint list, then use SharePoint Rest API in HTTP (SharePoint) action instead of Update Item action, Advantage of using Rest API over update item is Rest API allows updating only those columns which you want to update, whereas update item action forces you to provide values for required columns even though you don’t want to update its value, and sometimes it does make the values blank in a column if you don’t specify a value for that column in update item action.

d. Create flows using Service Account and then share the flow with users who will develop the flow, this way flow users service accounts in connections, and also the ownership of flow is not under any user.

e. If your flow becomes too big, consider breaking down into multiple flows, and you can use Run Child Flow or HTTP action to call the child flows.

f. The M365 environment which we worked with used Mimecast for email security and filtering. Since we had issues in making the email approval work as Mimecast blocks the actionable messages that are used by Power Automate to send email approvals. Hence, we had to bypass actionable messages from Mimecast filtering.

What’s Good and bad about migrating your Nintex forms/workflows to PowerApps/Power Automate
Good

What’s good about migrating your Nintex forms/workflows to PowerApps/Power Automate

1. If your app and workflow require only the standard connectors, then you don’t need to spend on extra licensing costs when your M365 licenses cover PowerApps and Power Automate.

2. PowerApps User Interface is much better than what users used in Nintex on-prem forms, so users will get a good user experience, and users can use the app directly from their mobile phones and tablets as PowerApps is available on mobile devices and it is responsive as well.

3. Approvals from emails/teams using Power Automate, is a good feature for users to quickly provide their approval decision, and once an approval decision is made the message is displayed to users that approval is completed.

4. If your workflow and form are simple it doesn’t take much time to develop the form and workflows, it’s a no-code solution so doesn’t require geeky developers to build it unless the workflow and forms are too complex. So, power users can also build forms and workflow and take help from developers when it starts to get complex.
Bad

What’s bad about migrating your Nintex forms/workflows to PowerApps/Power Automate

1. If your flows start growing in more number, and in size, then your flow runs will also increase and it may go over what is allowed in M365 license limits and that will affect your application, so this may delay the workflow instances to run. One way to resolve this issue is to use different service accounts across flows in the connections as the flow runs counted per user, so the more accounts you use, the more flow runs you get per day.

2. Flow does not have workflow history, so if you need workflow history for audit purposes, then you need to build logic in the workflow to save the important workflow information required step of the workflow. So involves more work.

3. If you expect your flow instance to run more than 30 days, then you will need to design your flow logic in such a way that it can last over 30 days by starting the new instance again automatically. By default, the Flow instance cannot last beyond 30 days, that’s the limit of Power Automate.

4. PowerApps Canvas apps do not have interactive repeating tables out of the box, so involves significant work in developing logic to load data in repeating tables, and save the data of repeating table back to the SharePoint list. So, this involves more work especially if you repeating tables has complex fields like people picker.

To conclude, you need to evaluate your Nintex forms and workflows, and determine as per your requirements, I have also worked on migrating Nintex forms and workflow from on-prem to Nintex Office 365, that also involves a lot of work of migration, first need to buy a tool like Sharegate for migration of Nintex forms and workflows, then there are a lot of controls, components, and actions which are supported in Nintex On-Prem but not support in Nintex Office 365, so that will also require rework in terms of replacing those controls, components and actions after migration to Office 365 in order to make your forms and workflows functional. Also, when you migrate Nintex forms to Office 365, it migrates forms in classic view, and Nintex Classic forms are not responsive, so if you need good looking forms then you need to redevelop those forms are Nintex responsive forms. So do a good DAR process before migration to weigh the pros and cons of migrating from Nintex On-Prem to Nintex Office 365 v/s migrating from Nintex On-Prem to Power Automate and PowerApps.