For years Active Directory Federation Services, or ADFS, has served as a robust identity bridge connecting on-premises resources to the cloud. Today Microsoft’s strategic direction is increasingly centred on Azure AD, now branded as Microsoft Entra ID, as its primary identity platform. 

While ADFS remains supported, its long-term development focus is clearly secondary to Entra ID, which now represents Microsoft’s core identity service. 

This shift presents a significant challenge for many large organisations, particularly those in the education and research sectors that rely on Shibboleth IdP to manage federated access. For them, migration is not a simple lift-and-shift exercise. A successful transition requires careful planning to maintain continuous Single Sign On SSO and ensure correct attribute flow between these complex identity systems. 

This guide provides a clear roadmap for migrating applications from ADFS to Azure AD. We focus specifically on navigating this transition while coexisting with, or fully transitioning from, a Shibboleth IdP environment. 

Why Migration Is Increasingly Necessary: The Benefits of Modern Identity (Entra ID) 

The move away from ADFS is largely driven by improvements in operational efficiency, security capabilities, and governance flexibility. For many organisations, it represents a strategic progression towards more resilient identity management. 

• Reduced Cost and Complexity: ADFS requires physical or virtual servers, ongoing certificate management, patching, and infrastructure monitoring. Azure AD / Entra ID is a cloud-native service, reducing infrastructure dependency and shifting responsibility for platform maintenance to Microsoft. This allows internal teams to focus more on strategic initiatives rather than server upkeep. 
• Enhanced Security and Compliance: Azure AD provides built-in modern security capabilities including Conditional Access policies, granular access controls, and support for phishing-resistant Multi-Factor Authentication (MFA). While some of these controls can be implemented within ADFS, they are more natively integrated and centrally managed within Entra ID. Migrating can therefore improve visibility and control over identity-based risk. 
• The Shibboleth Factor: Migration also presents an opportunity to reassess architectural complexity. Organisations operating both Shibboleth IdP and ADFS environments often accumulate layered federation configurations over time. By redesigning identity flows around modern federation patterns, it may be possible to simplify trust relationships and reduce reliance on legacy relay configurations. The result is often a cleaner and more manageable identity architecture. 

The Three Phases of a Successful Migration 

Phase 1: Discovery and Assessment 

The single most critical phase of any migration is discovery. You cannot move what you do not fully understand. Your ADFS environment holds years of accumulated configuration and complexity. 

Begin by compiling a complete inventory of all Relying Party Trusts (RPTs) currently configured on your ADFS servers. These RPTs represent every application, external service, and third-party partner that relies on ADFS for authentication. Pay close attention to RPTs that secure access to your internal Shibboleth resources, as these may require additional consideration during migration. 

Microsoft provides several tools to assist with this discovery process. For example, the ADFS application migration dashboard available within the Microsoft Entra admin centre can help organisations review their existing Relying Party Trust configurations and identify applications that may require further analysis before migration. 

However, environments with customised claim rules or non-standard configurations often require additional manual review. This assessment phase ultimately defines the scope and timeline of the migration project. 

Phase 2: Application Migration and Testing 

Once assessed, applications should be migrated in controlled waves. One of the most significant technical challenges in an ADFS migration involves ensuring the correct flow of identity data, commonly referred to as claims and attributes. 

ADFS uses Claim Rules to determine which user attributes are released to specific applications. During migration, these rules must be carefully mapped to the Azure AD token claims configuration. A common failure point in environments that also use Shibboleth is incorrect handling of group membership or education-specific attributes required by federated services. 

Implement a pilot and parallel run strategy. Avoid migrating all applications simultaneously. Configure the application in Azure AD / Entra ID while keeping the ADFS instance running in parallel. Test with a small user group using the new Azure AD configuration before transitioning access for the wider organisation. 

End-to-end testing should confirm that users can successfully authenticate and that applications receive the correct attributes required for authorisation. 

Phase 3: Cutover and Governance 

The final phase involves transitioning applications to the new identity platform and gradually decommissioning the legacy ADFS infrastructure. After successful pilot testing, applications can be updated to point fully to the new Azure AD configuration. 

If the organisation is migrating its entire user authentication model, the identity configuration may need to be adjusted from a federated authentication model to a managed or cloud authentication approach. In many environments this involves updating the Azure AD Connect configuration so that Azure AD becomes the primary authentication authority rather than relying on ADFS. 

Post-migration governance is equally important. Ensure that appropriate audit logging is enabled within Azure AD and establish a monitoring process to track authentication activity, unexpected access patterns, or attribute claim issues that may emerge in the weeks following the cutover. 

Bridging the Shibboleth Gap: Solving Dual Login Challenges 

While the move from ADFS to Azure AD resolves many operational challenges, it can introduce a new frustration for organisations running a mixed identity environment. Users may find themselves logging into Shibboleth resources and Azure AD resources separately. This dual login experience undermines the goal of Single Sign On and can create user friction as well as additional service desk requests. 

This challenge stems from the different ways these two identity providers manage sessions and authentication tokens. Without a mechanism to connect the two environments, users may be required to authenticate again when moving between a federated research application secured by Shibboleth and a corporate application secured by Azure AD. 

In these environments, additional configuration or specialised tooling is often required to link the authentication flow between the two providers. One approach is the use of a bridging mechanism that helps synchronise authentication sessions between the identity systems. 

Overt Software Solutions developed the  SAAM bridge (Shibboleth ADFS/Azure AD Authentication Module)  to support this type of integration. The SAAM bridge allows authentication from one environment to be recognised by the other, helping organisations provide a more consistent Single Sign On experience across both Shibboleth and Azure AD resources. 

You can learn more about the SAAM bridge and its cross-authentication capabilities on the Overt Software Solutions website or by simply pressing the button below: 

Achieving Modern Identity Resilience: Your Secure Path to Entra ID 

The migration from ADFS to Azure AD represents an important step for many organisations seeking improved security, reduced infrastructure overhead, and access to modern identity capabilities. 

However, the migration process can be complex, and the risk of misconfiguration increases in environments that rely on Shibboleth or other federated identity systems. Successfully managing the transition while addressing dual login challenges requires careful planning, thorough testing, and appropriate integration tools. 

The team at Overt Software Solutions provides specialist guidance to support organisations during ADFS to Azure AD migrations. We work with institutions that operate complex identity environments, including those using Shibboleth IdP for federated access. 

Our services help organisations manage attribute mapping, identity integration, and migration planning across both Azure AD and Shibboleth environments. The SAAM bridge developed by Overt Software Solutions is designed to help organisations connect authentication between these systems and reduce the friction of dual login experiences.