Legacy Application Migration Framework
& Entra ID Integration Guide
Reference Document for Migration Strategy, Governance, and Identity Architecture
1. Drivers for Migration
Business Drivers
- Cost Optimization: Shift from CapEx to OpEx; eliminate data center maintenance; leverage pay-as-you-go pricing (30-40% savings).
- Innovation: Faster time-to-market; access to AI/ML capabilities; experiment at scale without upfront hardware investment.
- Agility & Scalability: Dynamic auto-scaling for traffic spikes; rapid global expansion; simplified M&A integration.
- Risk Mitigation: Improved Disaster Recovery (RTO/RPO); automated backups; geographic redundancy.
Technical Drivers
- End-of-Life Systems: Mitigate risks of unsupported OS (e.g., Windows 2012), legacy databases, and aging hardware.
- Performance: Resolve monolithic resource bottlenecks; improve latency and user experience.
- Security & Compliance: Modernize security posture (Zero Trust); meet GDPR/HIPAA requirements; automated patching.
- Talent Availability: Address skills shortage in legacy tech (COBOL, older frameworks); improve retention.
2. Migration Decision Framework
| Criteria |
Migrate (Go Cloud) |
Retain (Stay On-Prem) |
Retire (Decommission) |
| Business Value | High strategic value; core differentiator. | Moderate value; nearing replacement. | Low/No value; redundant. |
| Tech Compatibility | Cloud-compatible / Refactor-ready. | Specialized hardware / Low latency needs. | Technically obsolete. |
| Compliance | Cloud provider meets certifications. | Strict data sovereignty restrictions. | No longer required. |
| Usage Patterns | Variable load; high growth. | Stable, predictable load. | Minimal usage. |
| Integration | Requires modern cloud APIs. | Isolated / Legacy dependencies. | Duplicate functionality. |
3. Application Types for Migration
- Web Applications: Intranets, portals, wikis, and CRM interfaces utilizing standard HTTP/S.
- Database-Centric Apps: OLTP systems, data warehouses, and reporting tools heavily reliant on RDBMS.
- Batch Processing & ETL: Scheduled jobs, data transformation pipelines, and nightly reports.
- Microservices / API-Based: Modern decoupled architectures, often containerized or ready for containers.
- Legacy Mainframe: COBOL/RPG systems on z/OS or AS/400 (often high complexity).
- SaaS Applications: Third-party hosted tools (Salesforce, M365) to be integrated rather than migrated.
4. RASCI Chart (Roles & Responsibilities)
| Role Group | Key Responsibilities |
|---|
| Executive Leadership | CEO: Vision & Budget. CIO: Strategy & Roadmap. CISO: Security Requirements & Risk Acceptance. CFO: TCO/ROI Analysis. |
| Technology Leadership | Cloud Architect: Target design & patterns. Security Architect: Zero Trust design. IAM Architect: Entra ID design & standards. Network Architect: Connectivity (VPN/ExpressRoute). |
| Operational Teams | Infra Team: IaC (Terraform/Bicep) & Deployment. App Dev: Code changes & readiness. IAM Ops: Entra ID config & app registration. DBA: Data replication & cutover. |
| Business & Support | Business Owner: Validation & UAT sign-off. PMO: Schedule & Risk tracking. Change Mgmt: Training & Comm. Legal: Data residency compliance. |
5. Workload Assessment Criteria
- Business Criticality: What is the impact of downtime? (Determines RTO/RPO).
- Technical Complexity: How coupled is the architecture? Are there hard-coded IPs or dependencies?
- Data Volume: Size of data? Transfer method (Network vs. Physical/Snowball)?
- Performance Requirements: Latency sensitivity? Compute/Memory demands?
- Compliance: Does the data fall under GDPR, HIPAA, or PCI-DSS?
- Dependencies: What upstream/downstream systems does this app talk to?
- Authentication: Does it use AD, LDAP, Kerberos, or Local DB users?
- Licensing: Can existing licenses be brought to cloud (BYOL)?
6. Application Portfolio Segmentation (4 Waves)
- Wave 1: Quick Wins (Pilot) — Low complexity, low criticality (e.g., Dev/Test envs, simple internal tools). Validates the process.
- Wave 2: Strategic Applications — High value, moderate complexity (e.g., Customer portals, analytics). Demonstrates ROI.
- Wave 3: Business Critical — High criticality, high complexity (e.g., ERP, Core Transaction Systems). Requires robust DR.
- Wave 4: Complex Legacy — Specialized hardware, Mainframes, or apps requiring total rewrite. Long-term transformation.
7. Application Types & Ideal Migration Strategies
1. Web Applications
Ideal: Replatform (PaaS). Move to Azure App Service. Gains auto-scaling and managed patching.
Alternative: Rehost (Lift & Shift) if OS dependencies exist.
2. Database-Centric Apps
Ideal: Replatform (Managed DB). Move to Azure SQL MI or Amazon RDS. Reduces admin overhead.
Alternative: Refactor if switching engines (e.g., Oracle to PostgreSQL).
3. Batch Processing & ETL
Ideal: Refactor (Serverless). Move to Azure Functions or Logic Apps. Pay only for execution time.
Alternative: Rehost (VMs) for complex legacy schedulers.
4. Microservices / API
Ideal: Relocate (Containers). Move to AKS/EKS. "Hypervisor-level lift and shift" for containers.
Alternative: Refactor to pure serverless event-driven architecture.
5. Legacy Mainframe
Ideal: Retain (with Wrapper). Expose via API Management while keeping core stable.
Alternative: Rehost via emulation on x86 cloud instances.
6. SaaS Applications
Ideal: Integrate (Replace). Retire on-prem equivalent, migrate data, and integrate Identity.
8. Entra ID Integration by Migration Strategy
A. Rehosted Applications (Lift & Shift)
Moving VMs to Cloud IaaS without code changes.
- Identity Approach: Secure remote access without VPN while maintaining legacy auth (Kerberos/Header).
- Component: Microsoft Entra Application Proxy
- Flow: User → Entra ID (MFA/CA) → App Proxy Connector → Kerberos Ticket (KCD) → Legacy App.
- Effort: Medium (Deploy connectors, config KCD).
B. Replatformed Applications (PaaS)
Moving to App Services / Managed Services.
- Identity Approach: Modernize authentication to standard federation protocols.
- Component: Entra ID Enterprise Applications (SAML/OIDC)
- Flow: User → App (PaaS) → Redirect Entra ID → Token → App.
- Effort: Low (Configuring reply URLs and claims).
C. Refactored Applications (Cloud Native)
Rewriting to Microservices/Serverless.
- Identity Approach: "API First" security using OAuth 2.0.
- Component: Microsoft Authentication Library (MSAL) + App Registrations
- Flow: Client (SPA) → Entra ID (Auth Code + PKCE) → Access Token → API (Validation).
- Effort: High (Code integration required).
D. Relocated Applications (Containers)
Moving Kubernetes clusters.
- Identity Approach: Ingress-level authentication or Workload Identity.
- Component: Entra Workload ID + Oauth2-Proxy
- Flow: Ingress Controller → OIDC against Entra ID → Pass Identity Header to Pod.
- Effort: Medium (K8s YAML configuration).
9. Entra ID Tech Stack by Migration Strategy
| Strategy |
Entra ID Components |
Integration Pattern |
Effort |
Considerations |
Rehost
(Lift & Shift) |
• App Proxy
• Conditional Access
• On-prem Connectors |
Pre-Authentication + Kerberos (KCD) or Header Injection |
Medium |
Best for legacy apps that support IWA/Kerberos but need remote access. |
Replatform
(PaaS) |
• Enterprise Apps
• SAML/OIDC Config
• App Provisioning (SCIM) |
Federated Auth (SAML/OIDC) |
Low |
Standard pattern for apps that natively support SAML (e.g., Jira, ServiceNow). |
Refactor
(Cloud Native) |
• App Registrations
• MSAL SDKs
• API Scopes/Roles |
OAuth 2.0 / OIDC (Auth Code Flow) |
High |
Allows fine-grained authorization logic using app roles and scopes. |
Relocate
(K8s/Containers) |
• Workload ID
• Managed Identities
• OIDC |
Ingress Controller Auth or Service Mesh |
Medium |
Decouples auth from application code by handling it at the cluster ingress. |
Note on Conditional Access: Regardless of the migration strategy chosen, all applications integrated with Entra ID benefit from Conditional Access Policies (MFA, Device Compliance, Location, User Risk) acting as the Zero Trust policy engine.