Migrating SharePoint 2016 to Subscription Edition When Authentication Isn't Simple

SharePoint Server 2016 and 2019 reached end of support on July 14, 2026. For many organizations, moving to SharePoint Server Subscription Edition (SPSE) is a fairly predictable project: build the new farm, attach the content databases, test, and cut over.

That predictability disappears when authentication isn't standard. We recently completed an SP2016-to-SPSE migration for an enterprise client with nearly 1,000 users and a global footprint, where signing in to SharePoint meant passing through several identity systems before a page ever loaded. Moving the content was the easy part. Moving the identity chain intact, without users noticing, was the real project.

Here's what we learned.

The Environment

Most SharePoint farms authenticate against Active Directory and stop there. This one didn't. Sign-in ran through a chain:

• ADFS as the federation layer SharePoint trusts
• NetIQ Access Manager backed by an eDirectory identity store, rather than Active Directory as the source of truth
• Okta, integrated with NetIQ to provide multi-factor authentication
• LDAPCP to resolve users and claims in the SharePoint people picker

On top of that, the farm served several web applications, integrated with a third-party workflow platform, and relied on Office Online Server for in-browser document editing. Every one of those pieces had to work the same way on SPSE as it did on SP2016.

For a deeper look at how this identity architecture was originally designed, read: Beyond Active Directory: Integrating NetIQ Access Manager and Okta with SharePoint

Lesson 1: Design the Cutover So Users Never Notice

The biggest risk in a migration like this is the cutover itself. Change the wrong federation setting and a thousand users around the world hit a login error at the same time.

We designed the ADFS configuration so production cutover required no identity changes at all. A single ADFS relying party trust was extended across multiple web applications, with a unique realm identifier for each one. That let the new SPSE farm take over each web application's existing identity relationship cleanly, instead of rebuilding trusts during a maintenance window.

The principle applies to any complex migration: move the risky work into the build phase, where you can test it, and keep cutover as close to "flip the switch" as possible.

Lesson 2: Keep a Windows Authentication Zone for the Plumbing

Federated sign-in works well for people. It works poorly for SharePoint's own background services. Search crawling, service accounts, and cache accounts all need to authenticate, and they can't complete an MFA prompt.

We ran a dual-zone design: ADFS for users, and Windows (NTLM) authentication on a separate zone for internal services. Early on, this surfaced "Access Denied" errors that had nothing to do with user permissions. The cause was SharePoint's object cache accounts, which needed policies matching the claims-based identities on the new farm. Once those were aligned, the errors cleared.

If you see Access Denied on a new claims-based farm and the user's permissions look correct, check the object cache account policies before anything else.

Lesson 3: Your Directory Schema Matters More Than You Think

Because the identity store wasn't Active Directory, the attributes SharePoint depended on didn't always exist where expected. While building the development farm, NetIQ returned authentication errors that traced back to missing schema elements: an auxiliary object class and email attributes that the claims configuration relied on.

The fix was straightforward once found. Finding it required tracing a claim all the way from SharePoint back through ADFS and NetIQ to the directory. In a multi-provider setup, every claim SharePoint consumes has a source, and each source needs to be verified in every environment you build.

Lesson 4: Claims Augmentation Can Cost You at Login

After the new farm was up, users saw noticeably slow logins. The network, the servers, and ADFS were all fine. The delay came from claims augmentation in LDAPCP, which was looking up additional user information at every sign-in.

Isolating that step, rather than guessing at infrastructure, was what mattered. We also resized SharePoint's Distributed Cache from roughly 800 MB to nearly 9 GB. The default sizing wasn't close to adequate for a farm of this size and authentication complexity, and an undersized cache shows up to users as slow, inconsistent sign-in behavior.

Lesson 5: The Details That Break on Day One

A handful of smaller issues each had the potential to stall the project:

• Content database conflicts. Databases that had been restored or copied during testing collided on internal IDs when mounted. Mounting them with a new database ID resolved it.
• Sign-in page customizations. ADFS home realm discovery relied on a custom script that had to be re-imported into the ADFS theme on the new configuration.
• Office Online Server. In-browser editing had to be rebound to the new farm, and PDF handling reconfigured.
• Add-ins and workflow integration. SharePoint add-ins needed new hosting infrastructure, including certificates and an app domain. We confirmed the workflow platform's integration was unaffected before cutover.

Not every problem is yours to solve alone. One issue with SharePoint-hosted add-ins turned out to be platform behavior in SPSE, and we escalated it to Microsoft support instead of burning project hours on workarounds. Knowing when to open a case is part of running a migration well.

Lesson 6: Build It Three Times

The approach that made this migration predictable was also the least glamorous. We built development, then QA, then production, and documented every step in a runbook as we went. Each environment surfaced problems the previous one didn't. By the time we reached production, the build was a sequence of known, tested steps.

We work in small increments and verify each change before moving to the next. On a system with this many dependencies, a single unverified change can take hours to trace back.

Still on SharePoint 2016 or 2019?

Support has ended. That means no more security updates, which matters most for exactly the kind of farm described here: internet-facing, federated, and holding years of business content.

If your SharePoint environment has non-standard authentication, heavy integrations, or a global user base, the migration is very doable, but it needs a plan that treats identity as the main workstream, not an afterthought.