Extend Microsoft Entra ID to complex apps with Identity Orchestration

Moving to a modern cloud IDP, like Microsoft Entra ID*, has many benefits — we’re not here to convince you of that. Yet, because application migrations are so complex, they take a long time. Although most enterprises intend to transition as much as possible to the cloud, an average of 75% of workloads are still on-premises. Modernizing identity in legacy apps requires manually rewriting code, eating up precious developer resources (that most organizations can’t afford). 

Adopting a hybrid or multi-cloud strategy often results in fragmented identity systems and lock-in to legacy on-premises systems that strain resource-strapped teams to the breaking point.  According to a recent Forrester study: 

• 78% find managing user identities between multiple clouds to be a top challenge
• 58% can’t implement consistent policies when identities are scattered

With identity at the center of a business’ digital infrastructure, ensuring teams can access the tools they need with the right permissions — without compromising security or compliance policies is essential. Identity Orchestration is a new distributed identity solution that eliminates many challenges of migrating legacy, on-prem apps to Microsoft Entra ID. 

We’ll explore what makes app migrations so painful and some techniques needed to manage application modernization projects successfully. Then, discover how Identity Orchestration gives enterprises the power to quickly transition legacy apps to Microsoft Entra ID without rewriting.

Common identity challenges when migrating to Microsoft Entra ID   

Microsoft Entra ID can improve security, provide users with a better experience, and enable the benefits of the cloud. However, the migration path to Entra ID is not without hurdles, including the need for co-existence between on-prem and cloud workloads, the time it takes to rewrite legacy application code, and maintaining consistent access policies between environments.  

Challenge 1: Balancing the co-existence of on-premises and cloud IDPs

The digital landscape is constantly evolving. Enterprises now have several cloud identity services driving the need for new and old systems to co-exist, which introduces complexity when managing security and risk. In fact, the single largest multi-cloud identity challenge is enforcing a common policy across a mixed set of clouds.

Moving from a legacy IDP to the cloud is a long process; moving everything over all at once from a legacy IDP to Azure AD can lead to the failure of the entire migration project and put you back at square one.                                                                                                                                                                                                                                                

Challenge 2: Rewriting legacy application code to work in the cloud 

Modernizing apps is critical in the digital transformation journey. Not only is it time-consuming and expensive, but it also hampers your business’s ability to stay competitive in a rapidly changing market. Rewriting applications for identity updates requires developer time that should instead be spent on revenue-generating projects.

Transitioning on-premises applications from legacy identity systems to a standards-based cloud identity system typically also requires significant changes for operational teams. The cost is a big investment of developer bandwidth and budget. With more complex apps, expect to double or triple the amount of time and money it will take. 

Challenge 3: Maintaining consistent access policies

An estimated 74% of organizations struggle with running multiple identity systems to support distributed identities. Maintaining each separate identity system results in inconsistent access policies and identity data when each identity system expects to be the authoritative system of record. The result is fragmentation, loss of control, and over-provisioning, which hinders a strong security posture and increases risk.

Six steps for migrating on-premises apps to Microsoft Entra ID

The challenges are real, and whoever nicknamed migration ‘lift-and-shift’ may have been oversimplifying; manually refactoring apps involves multiple phases that require careful planning and execution. This guide aims to provide a quick overview of these phases, from policy discovery to change management, helping you understand what to expect during the migration process and how to prepare effectively. Let’s start with the first step: 

1. Discovery of policies

Before embarking on the journey of refactoring, understanding the application’s current state is paramount. This involves an in-depth discovery of the existing policies and configurations that the application abides by. By cataloging these, compliance continuity is clearer and identifying areas requiring attention during the migration can be prioritized.

2. Rewriting the app’s code

Once the discovery is done, the next phase is to rewrite or modify the application’s codebase. This process ensures that the application aligns seamlessly with the new IDP’s architecture and protocols. It’s an arduous  task, often demanding the expertise of seasoned developers to ensure code efficacy to maintain the application’s core functionalities.This is also the stage that developers might get stuck on if an app was written years ago and access to the source code is a challenge. 

3. Testing in test or non-production environments

After code updates have been completed, applications undergo rigorous testing in dedicated test environments. These environments emulate real-world scenarios, allowing for the detection of bugs, vulnerabilities, or inconsistencies. Ensuring that the application operates flawlessly here is a precursor to a successful migration in a live setting. Many customers have multiple test environments and may need to repeat these steps several times. 

4. Testing in production environments

While test environments offer valuable insights, the real litmus test lies in the production environment. Testing in production offers a real-world evaluation, identifying how the refactored application interacts with live data, user loads, and other dynamic variables. It’s a crucial phase to ascertain the application’s readiness for full-scale deployment post-refactoring. This is also the stage where the live app will be temporarily down. The more critical and revenue-driving the app is, the more challenging it will be to get this phase done right. 

5. Scheduling changes with the app’s owner

Collaboration is vital in ensuring a seamless transition. Once testing phases are complete and the application is deemed ready, changes are scheduled in conjunction with the app owner. This coordination ensures that both the development team and the stakeholders are aligned, minimizing potential disruptions during the transition phase.

6. Change management & downtime considerations

The actual process of migration might necessitate some downtime or limited application availability. Hence, effective change management strategies must be in place. This involves pre-informing users, considering peak usage times to minimize disruptions, and having contingency plans ready in case of unforeseen challenges. Efficient change management is the cornerstone of ensuring user trust and service continuity during the refactoring process.

These six phases provide a good baseline framework for the refactoring process. By adhering to these outlined steps and emphasizing meticulous planning and testing, a smooth transition is possible.

How long it really takes to migrate on-premises apps to Microsoft Entra ID

Now that we know what each app has to go through to get refactored for a new IDP, Microsoft Entra ID in our case, we need to understand how long it will take to modernize each type of application to avoid expensive delays. The more complex the app and IAM infrastructure, the more days you can expect to tack onto your project. 

Legacy, on-premises applications are generally not standards-based. Meaning they were built before the creation of modern identity standards like SAML and OIDC. If an app is non-standards-based, it will take much longer to modernize because of the time needed to rewrite these complex apps. 

Exactly how much more? It depends on the complexity of the systems and whether the app in question is considered “easy” or “hard” to migrate. Several pivotal questions should be asked to determine the true complexity and thereby estimate migration time:

• Does the app speak modern identity protocols like OIDC and SAML?
• Is the application expecting headers?
• Does the application also need attributes from one or more attribute stores?
• Does the application have a login form (to access LDAP or other database attributes)?
• Will the app require a 3rd party callout or response?

We talked with customers about the qualities of difficult and easier apps and the estimated time it might take them to refactor said apps. Here’s what they said: 

1. Refactoring an “easy/medium” application 

• Duration: Approximately 12 weeks, translating to 60 working days or a total of 480 working hours.
• Integration considerations: This category typically includes applications that have certain dependencies on other systems or applications. However, these dependencies might not be overly convoluted, ensuring a smoother transition during the refactoring process.
• Standards compliance: Applications in this category may have their foundation in legacy systems. Nevertheless, they still might use older but widely recognized technologies that ensure a degree of compatibility during the refactoring process.
• Complexity parameters: Applications that fall into this class often necessitate external authorization protocols. They might involve attribute manipulations and possess a moderately intricate logic that needs careful handling during the refactoring.

2. Refactoring a “hard” application

• Duration: A minimum of 24 weeks is estimated, translating to 120 working days or a cumulative of 960 working hours.

• Integration considerations: Applications in this segment have deep-rooted connections with other systems. This could involve frequent interactions with legacy APIs, making the migration process more demanding ontime and resources.
• Standards compliance: A significant challenge in this category is that these applications might not recognize modern standards such as SAML or OIDC. Such  non-compliance would often necessitate a considerable amount of refactoring to make the application compatible with current systems.
• Complexity parameters: Hard-coded values, specific decoding processes, or the presence of custom authorization modules characterize the applications in this bracket. These complexities do not just reside in the codebase but can also stem from organizational structures. Collaboration challenges could emerge due to teams working in silos, introducing an additional layer of complexity to the migration process.

Total average application migration project duration: On-prem to Microsoft Entra ID 

Enterprises, depending on their scale and age, often possess anywhere from a handful to thousands of applications requiring modernization. Let’s take a hypothetical scenario — an organization that has 100 applications. How does such an organization handle the migration process?

Typically, the application complexity breakdown for most enterprises is around 80% for easy/medium applications and 20% for hard ones. Given this distribution:

• 80 applications (easy/medium complexity) would take 60 days each for refactoring, considering the stages we discussed earlier.
• The remaining 20 applications (of higher complexity) would each need about 120 days for refactoring.

If you were to refactor these applications manually and sequentially, the math points to a daunting 28 years! It’s clear now why legacy IAM infrastructure still looms large and tech debt is a very real challenge in many enterprises. That said, most organizations would concurrently refactor multiple applications, so this time frame isn’t practically as lengthy.

How Identity Orchestration speeds up app migrations 

Now, let’s explore the expedited process with Identity Orchestration assistance:

• The same 80 easy/medium complexity applications are refactored in just a day each.
• The 20 hard applications are migrated in merely six days each.

In total, that’s about 200 days (or seven months when rounded up). Again, this calculation assumes a one-at-a-time migration, which isn’t in line with reality. The actual migration time, thanks to incrementally migrating a batch of apps, would be even shorter.

For a more detailed perspective, refer to the illustrative breakdown below. This chart simplifies the migration journey by coupling the estimated timeframes with the respective number of applications. The side-by-side comparison showcases the stark difference between a conventional migration and the efficiency of one powered by Identity Orchestration.

Identity Orchestration extends Microsoft Entra ID to on-prem apps

In our rapidly evolving digital landscape, hybrid or multi-cloud operations are more a rule than an exception. Catering to this dynamic environment, Identity Orchestration emerges as a beacon of hope. This innovative approach to distributed identity management provides an accelerated path for enterprises eager to transition from traditional systems to Microsoft Entra ID, without rewriting applications and getting stuck with the timelines discussed in the previous section. 

The magic lies in the “identity fabric.” This layer abstracts the identity from the app, paving the way for Identity Orchestration to seamlessly weave Microsoft Entra ID’s authentication and access protocols into on-premises applications, even if they’re deep-rooted in legacy identity systems.

Zooming out to see the bigger picture, here are some standout benefits of adopting Identity Orchestration in your migration journey…

Benefits of using Identity Orchestration to migrate legacy apps to Microsoft Entra ID

Consistent identities and policies are necessary to reduce security risks, decrease user friction, and enhance an organization’s journey to reaching zero trust. Identity Orchestration can: 

1. Save millions of dollars by avoiding costly application rewrites required to move to standards-based authentication and SSO.
2. Improve security by seamlessly adding multi-factor and risk-based authentication and access control to legacy password-protected apps.
3. Reduce fragmentation by retiring redundant, complex, fragile, and extremely high-cost legacy identity software before it reaches its end of life.

In a world where digital transformation is paramount, ensuring efficient and secure identity management is crucial. Identity Orchestration offers a pathway to simplify this journey, allowing businesses to harness the power of Azure AD without being bogged down by the intricacies of app refactoring for modernization. 

Strata is here to help you navigate the challenges of migrating your most stubborn apps to Azure AD. Take advantage of our complimentary working session to review your unique requirements and expedite your upcoming (or in-progress) migration to Azure AD.

*Azure AD is now called Microsoft Entra ID. From Microsoft on July 11, 2023:

The  name change to Microsoft Entra ID represents the evolution and unification of the Microsoft Entra product family, and a commitment to simplify secure access experiences for everyone.