The Forms Migrator, when migrating data sources and form designs to a new SharePoint Online site, requires certain permissions in order to create lists, migrate data, and optionally deploy form designs. This is a guide to the permissions required for each function of the Forms Migrator.
Reading Source Lists or Form Libraries (InfoPath, Nintex, PDF, etc.)
What you need:
Read permissions on the source list or form library.
Why:
Forms Migrator must be able to read the existing schema, items, and attachments to generate the target structure or migrate data. Read access is sufficient—no editing or administrative control is needed at this stage.
Generating Target SharePoint Lists
What you need:
Edit permissions on the destination site (commonly granted through the Members group).
Why:
The tool creates a new SharePoint list and columns based on your source form structure. Edit rights allow creation and modification of lists and list settings.
Migrating Data
What you need:
Edit permissions on the destination list.
Why:
To write list items, upload attachments, and maintain field mappings, the Migrator needs the ability to insert and update content. Again, standard "Edit" permissions from a Members group are typically enough.
Creating PDFs During Migration
What you need:
Edit permissions on the destination list or library where PDFs will be stored.
Why:
When the Migrator renders and stores PDFs, it needs the ability to save files to SharePoint. No additional admin roles are required.
Deploying Custom Forms (Lightning Forms or skybow Forms)
What you need:
Site Owner / Full Control on the target site.
Why:
Deploying a custom form (e.g., Lightning Forms or skybow Forms) modifies site-level components such as list forms, scripts, or solution elements. Only Site Owners have the rights to apply or update these configurations.
Important:
This does NOT apply when migrating to Power Apps or when performing a data-only migration.
For those scenarios, standard Edit permissions remain sufficient.
Authentication Requirements (Admin Consent vs. Browser Login)
Default Authentication
When logging in with a Microsoft 365 Work/School account, the application normally requires Admin Consent to operate with elevated scopes. The first time you attempt to connect to a SharePoint Online source or target site, you'll see a dialog asking to approve the AllSites.Manage delegated permission in Entra; this approval must be done by an administrator. If you are writing to Lightning Forms or skybow Modern Forms, approval of the AllSites.FullControl delegated permission must also be granted.
If you do not wish to use the built-in App Registration, you can create your own in Entra, granting it the required permission.
Consent is granted to the App, not the user account.
Browser Login Option
If Admin Consent hasn’t yet been granted, users can attempt the Browser Login method.
This allows you to authenticate without requiring Azure AD admin approval.
It’s ideal for quick testing or proof-of-concept scenarios.
Important caveat:
This method does not always work—particularly in environments using:
Network appliances that cache or inspect session objects
Cookie-stripping or token-hardening security tools
Reverse proxies that interfere with browser session persistence
When it works, Browser Login avoids the need to involve your security team just to test things out. If it fails, proceed with standard Admin Consent.
Summary Table
Task |
Required Permission |
Notes |
|---|---|---|
Read source list / form library |
Read |
Needed to read schema and items |
Generate destination SharePoint list |
Edit |
Usually via Members group |
Migrate data |
Edit |
Needed to insert/update items and attachments |
Generate PDFs |
Edit |
Needed to write files to library |
Deploy Lightning Forms or skybow Forms |
Full Control / Site Owner |
Required for form customisation deployment |
Deploy Power Apps |
Not required |
Standard Edit permissions are enough |