SharePoint On-Premises Support Matrix

Which SharePoint Server (on-premises) deployments MigrationFox can migrate today, what is coming post-launch, and how to confirm your specific environment before signing up.

Why on-premises SharePoint is hard for every migration tool

Cloud-to-cloud migrations are straightforward: both sides expose well-documented OAuth + REST APIs. SharePoint on-premises is a different beast because every customer authenticates differently. The same SharePoint 2019 binary can be configured for any of these auth models — or several at once:

• NTLM — classic Windows Integrated Authentication. Username + password verified against Active Directory. Used by most SharePoint 2010 / 2013 deployments and many SharePoint 2016 / 2019 deployments that haven’t moved to federated auth.
• Kerberos — encrypted ticket-based auth, often used alongside NTLM in mixed environments. SharePoint can be configured for Kerberos-only (no NTLM fallback).
• SAML / ADFS / Federated SSO — the SharePoint server redirects to an identity provider (ADFS, Okta, Ping, custom IdP) for a SAML assertion. Used heavily by enterprises with single sign-on requirements.
• App-Only OAuth (SharePoint Add-In credentials) — a Client ID + Client Secret pair registered via appregnew.aspx. Bypasses user authentication entirely; the migration tool authenticates as an “app principal” with site-scoped permissions.
• Forms-Based Authentication (FBA) — a custom login page backed by a user store (SQL, LDAP, ASP.NET membership). Rare in modern deployments but exists.
• Multi-Factor Authentication (MFA) — layered on top of any of the above; even with the right username and password, a second factor is required.

Each auth model needs a different code path inside the migration tool. There is no “just use Graph” equivalent for on-premises SharePoint. MigrationFox covers one auth model today and is building support for the rest in priority order based on real customer demand.

The full support matrix

Authentication model	SP versions	Today	Roadmap
NTLM via Windows agent	2010 / 2013 / 2016 / 2019	Supported	—
App-Only OAuth (SharePoint Add-In)	2013 / 2016 / 2019	Coming Q3 2026	Highest-priority post-launch build. Covers most federated environments.
WS-Trust active SAML (headless ADFS)	2013 / 2016 / 2019	Coming Q4 2026	Username + password → IdP → SAML → FedAuth cookie.
Internet-direct connection (no agent)	2013 / 2016 / 2019	Coming Q4 2026	For publicly reachable SP servers. Skips the agent install.
Pure-Kerberos (no NTLM fallback)	2013 / 2016 / 2019	Not yet	Rare in 2026. Contact us if this is your environment.
Forms-Based Authentication (FBA)	2010 / 2013	Not yet	Custom SQL / LDAP membership providers. Contact us with details.
MFA-required service accounts	Any	Not directly	Workaround: register App-Only credentials (post-launch); App-Only bypasses MFA.

Setting up NTLM migration (supported today)

Step-by-step for the supported path:

1. Confirm NTLM is enabled on your SharePoint web application. From SharePoint Central Administration → Application Management → Manage web applications → select your web app → Authentication Providers → Default zone → confirm Integrated Windows authentication: NTLM is selected (or NTLM + Negotiate).
2. Create a service account in Active Directory with the format DOMAIN\sp-migration. This account must have Site Collection Administrator rights on the source site collection (or at minimum Read + browse permissions on every site / library you intend to migrate).
3. Confirm the service account is exempt from MFA. If your environment enforces MFA on all accounts, you will need to either exempt this service account specifically (recommended) or wait for the App-Only OAuth support coming in Q3 2026.
4. Download and install the MigrationFox Windows agent on a Windows machine that can reach the SharePoint server — either on the same local network or via VPN. The agent runs as a Windows service and relays migration requests from MigrationFox’s cloud to your on-premises SharePoint. See Agent Troubleshooting for installation and operational details.
5. Add a SharePoint On-Premises credential in the MigrationFox dashboard. Provide the site URL (e.g., https://sharepoint.yourcompany.local/), the agent (pick from the dropdown of registered agents on your tenant), and the service account credentials in DOMAIN\user format. Click Test Connection — this must succeed before the Save Credential button activates.
6. Start a migration using the SharePoint & OneDrive wizard. The agent will be the source-side relay; the destination can be cloud SharePoint, OneDrive, or any of the supported file destinations.

Self-check: is your environment supported today?

Answer these three questions to determine whether you can migrate today or need to wait for a post-launch feature:

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

• “They enter their Active Directory username and password” → likely NTLM → supported today, continue to Question 2.
• “They get redirected to a separate sign-in page” (Okta, ADFS, Microsoft Entra, custom) → federated / SAML → not supported today, App-Only OAuth coming Q3 2026.
• “A pop-up asks for credentials inside the SharePoint window” → could be NTLM or Forms-Based — ask your SharePoint admin which Authentication Provider is configured.

Question 2: Can you obtain a Windows / AD service account exempt from MFA?

• Yes → you’re ready. Continue to NTLM setup above.
• No, all accounts in our tenant require MFA → wait for App-Only OAuth (Q3 2026) or contact your SharePoint admin about registering an App-Only credential as a workaround.

Question 3: Can the agent host reach the SharePoint server?

• Yes — on the same local network → install the agent on any Windows machine on that network.
• Yes — via VPN → install the agent on a Windows machine that has the VPN connection always active (not a personal laptop where the VPN gets disconnected when you go home for the day).
• No → SharePoint is in a closed network with no inbound or outbound paths to a migration-capable host. Wait for the Q4 2026 internet-direct mode, or work with your network team to provision a dedicated migration host.

Not sure? We’ll tell you in one business day

If any of the questions above are unclear, send an email to support@migrationfox.com with these three details:

1. SharePoint version (2010 / 2013 / 2016 / 2019 / unknown — we’ll help you find it)
2. Authentication setup (classic Active Directory / federated SSO / ADFS / Okta / Microsoft Entra / other — or just “not sure”)
3. Whether MFA is enforced on service accounts in your tenant

We’ll respond within one business day with a clear answer: supported today, on the post-launch roadmap with an expected date, or needs a custom integration. We won’t take your money for a migration we can’t complete — transparency on the front end saves everyone time.

Why we don’t ship all auth models at launch

Every authentication path in the matrix above is a meaningful engineering investment — not because the protocols are unknown (they’re all well documented), but because each one introduces a new failure surface, a new credential format, a new flow of redirects and cookies, and a new set of edge cases that customers will inevitably surface. Shipping each auth model means committing to maintaining it: when Microsoft updates the WS-Trust handshake or rotates a TLS cipher suite, customers running through that code path expect us to keep up. Shipping a half-tested auth model at launch would cost more in support burden and customer trust than waiting.

Instead, we’re launching with the auth model that covers the majority of practical migrations (NTLM via agent), being transparent about the roadmap for the rest, and using real customer signups in the first 30 days to validate which auth model we build next. App-Only OAuth is at the top of the queue because it unlocks the largest share of federated environments with the smallest engineering scope.