SharePoint On-Premises Support Matrix

What MigrationFox can do with SharePoint Server (on-premises) today, which sign-in methods it understands, and how to check your environment with us before you plan a project.

Why on-premises SharePoint is different

Cloud-to-cloud migrations use the providers' own sign-in and APIs. SharePoint Server is reached inside your network, and each farm can be set up for a different sign-in method, or several at once:

• NTLM: classic Windows Integrated Authentication. Username and password checked against Active Directory. Common on SharePoint 2013, 2016 and 2019 farms that haven't moved to federated sign-in.
• Kerberos: ticket-based sign-in, often alongside NTLM. A farm can be set up for Kerberos only (no NTLM fallback).
• SAML / ADFS / federated SSO: SharePoint redirects to an identity provider (ADFS, Okta, Ping or similar) for sign-in.
• App-only credentials (SharePoint Add-In): a client ID and secret registered with appregnew.aspx.
• Forms-based authentication (FBA): a custom sign-in page backed by SQL, LDAP or ASP.NET membership.
• Multi-factor authentication (MFA): a second factor on top of any of the above.

Each method needs its own code path. MigrationFox supports NTLM today.

The support matrix

Sign-in method	SharePoint versions	Today
NTLM through MigrationFox Desktop	2013 / 2016 / 2019	Connect and test: available. Migration (files only): limited early access
App-only credentials (SharePoint Add-In)	2013 / 2016 / 2019	Not supported
SAML / ADFS / federated SSO	2013 / 2016 / 2019	Not supported
Direct connection over the internet (no PC inside your network)	Any	Not supported
Kerberos only (no NTLM fallback)	Any	Not supported
Forms-based authentication	Any	Not supported
Accounts that require MFA	Any	Not supported. Use an account that signs in with NTLM without a second factor.
SharePoint 2010	2010	Not supported

Connecting an NTLM site

1. Confirm NTLM is enabled on the web application. In SharePoint Central Administration → Application Management → Manage web applications → select the web app → Authentication Providers → Default zone, check that Integrated Windows authentication with NTLM (or Negotiate with NTLM fallback) is selected.
2. Use an account that can read the content, in DOMAIN\user format. It needs at least read access to every site and library you want to copy. Site Collection Administrator on the source site collection is the simplest choice.
3. Install MigrationFox Desktop on a Windows PC or server that can open the SharePoint site (on the same network or over an always-on VPN). Download it from app.migrationfox.com/download/desktop and sign in. See MigrationFox Desktop troubleshooting for install details.
4. Add the connection on the web dashboard. On your project's Connect tab, find SharePoint On-Premises and click + Add SharePoint On-Premises. (In the Desktop app, the On-Premises option opens this page on the dashboard.) Enter a Label, pick the PC under Agent, and enter the SharePoint Site URL (for example https://sharepoint.contoso.local/sites/HR), Username and Password. Tick SharePoint uses a self-signed SSL certificate (skip validation) only if the server uses an internal or self-signed certificate.
5. Click Test Connection. The test runs from the PC you picked, not from the MigrationFox cloud. Save Credential becomes available once the test succeeds.

What a SharePoint Server migration copies

• Copied: files and folders in the document library you choose, and their created and modified dates when you keep that option on.
• Not copied: lists, metadata columns, version history, permissions, pages and web parts, workflows.
• Skipped: server page files that SharePoint Online and OneDrive reject (.aspx, .asmx, .ashx, .master).
• Data path: files stream from SharePoint Server through the PC to the destination. They are not written to the PC's disk and don't pass through MigrationFox servers.

InfoPath forms on SharePoint Server

If your goal is to archive InfoPath form submissions, you don't need a SharePoint Server connection. Export the form library's XML files and the form template (.xsn) to a folder, then run the InfoPath PDF Archive from that folder with MigrationFox Desktop. From Desktop 0.6.24, each form is turned into a PDF on that PC (earlier versions sent each form to MigrationFox to be rendered).

Self-check: does your environment fit?

Question 1: How do users sign in to your SharePoint server?

• “They enter their Active Directory username and password” (or are signed in automatically on domain PCs): likely NTLM. Continue to Question 2.
• “They get redirected to a separate sign-in page” (ADFS, Okta, Microsoft Entra or similar): federated sign-in, not supported.
• “A custom sign-in page inside SharePoint”: possibly forms-based authentication. Ask your SharePoint admin which authentication provider is configured.

Question 2: Do you have an account that signs in with NTLM without MFA?

• Yes: continue to Question 3.
• No, every account requires MFA: not supported today.

Question 3: Can a Windows PC or server reach the SharePoint server?

• Yes, on the same network: install MigrationFox Desktop on that PC.
• Yes, over VPN: use a PC where the VPN stays connected for the whole migration (not a laptop that disconnects overnight). Turn on Background mode in the app's Settings if it should run with nobody signed in.
• No: MigrationFox can't reach the farm. Work with your network team to provide a PC that can.

Check with us first

Before planning a SharePoint Server migration, email support@migrationfox.com with:

1. SharePoint version (2013 / 2016 / 2019 / Subscription Edition / not sure)
2. Sign-in setup (classic Active Directory / federated SSO / ADFS / Okta / other, or “not sure”)
3. Whether MFA is enforced on the account you would use
4. Roughly how much content and how many site collections

We'll tell you plainly whether your environment fits what MigrationFox supports today. We would rather say no up front than take on a migration we can't complete.