Cloud Migration Challenges and Solutions

𝐖𝐞 𝐬𝐩𝐞𝐧𝐭 €𝟏𝟎𝟎𝐤 𝐦𝐢𝐠𝐫𝐚𝐭𝐢𝐧𝐠 𝐭𝐨 𝐭𝐡𝐞 𝐜𝐥𝐨𝐮𝐝. Then we spent €100k migrating back. Eighteen months after the migration, critical workloads were back on-premise. What went wrong wasn't the cloud. The assumption was that moving would fix things. Their on-premise system was tightly coupled, hard to scale, and expensive to maintain. They assumed the cloud would solve this. Instead, they got: • The same tight coupling is now distributed across availability zones • The same scaling problems now with unpredictable monthly bills • The same maintenance burden plus new cloud-specific complexity The architecture didn't change. Only the hosting bill did. Here's what they learned: 𝐌𝐢𝐠𝐫𝐚𝐭𝐢𝐨𝐧 𝐢𝐬 𝐧𝐨𝐭 𝐦𝐨𝐝𝐞𝐫𝐧𝐢𝐳𝐚𝐭𝐢𝐨𝐧. Moving a monolith to the cloud gives you a cloud-hosted monolith. The problems travel with the code. 𝐓𝐡𝐞 𝐜𝐥𝐨𝐮𝐝 𝐚𝐦𝐩𝐥𝐢𝐟𝐢𝐞𝐬, 𝐧𝐨𝐭 𝐟𝐢𝐱𝐞𝐬. Good architecture becomes more scalable. Bad architecture becomes more expensive. 𝐋𝐢𝐟𝐭-𝐚𝐧𝐝-𝐬𝐡𝐢𝐟𝐭 𝐢𝐬 𝐭𝐞𝐜𝐡𝐧𝐢𝐜𝐚𝐥 𝐝𝐞𝐛𝐭 𝐰𝐢𝐭𝐡 𝐚 𝐧𝐞𝐰 𝐚𝐝𝐝𝐫𝐞𝐬𝐬. You're not paying down debt, you're relocating it. The cloud is a powerful tool. But tools don't fix design. If your architecture is fighting you on-premise, it will fight you in the cloud with a larger budget. 𝐁𝐞𝐟𝐨𝐫𝐞 𝐲𝐨𝐮𝐫 𝐧𝐞𝐱𝐭 𝐦𝐢𝐠𝐫𝐚𝐭𝐢𝐨𝐧: 𝐢𝐬 𝐭𝐡𝐢𝐬 𝐚 𝐡𝐨𝐬𝐭𝐢𝐧𝐠 𝐩𝐫𝐨𝐛𝐥𝐞𝐦 𝐨𝐫 𝐚𝐧 𝐚𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞 𝐩𝐫𝐨𝐛𝐥𝐞𝐦?

7 Cloud Migration Strategies Every Cloud Engineer Should Know (with scenario questions for interviews) Cloud migration can originate from on-premises infrastructure or from another cloud provider. And it goes beyond just moving data. It's about strategically deciding the best approach for each application and workload. The goal is to optimize performance, cost, and long-term viability in the cloud. Here’s a simple breakdown of the key strategies you should focus on: 1/ Retain (Revisit later) ↳ Keep workloads on-prem if they aren’t cloud-ready or are still needed locally. Scenario : You have a critical legacy application with custom hardware dependencies. How would you initially approach its cloud migration? 2/ Retire (Decommission) ↳ Eliminate outdated or unused parts to reduce cost and simplify the system. Scenario : During an assessment, you identify an old reporting tool used by only a few employees once a month. What's your recommendation? 3/ Repurchase (Drop & Shop) ↳ Replace legacy apps with SaaS alternatives, a fast and cost-effective solution. Scenario : Your company's on-premise CRM system (example) is outdated and costly to maintain. What quick cloud solution might you consider? 4/ Rehost (Lift & Shift) ↳ Move your application to the cloud as-is, with no code changes needed. Scenario : A non-critical internal application needs to move to the cloud quickly with minimal disruption. What strategy would you prioritize? 5/ Replatform (Lift, Tinker & Shift) ↳ Make light optimizations before migration, for better performance with minimal effort. Scenario : You're migrating a web application, and a small change to its database will significantly improve cloud performance. What strategy does this align with? 6/ Relocate (Many Providers) ↳ Change the hosting provider without modifying the app, a quick and simple approach. Scenario : Your current cloud provider is increasing prices significantly for a specific set of VMs. How might you address this without rewriting applications? 7/ Refactor (Re-architect) ↳ Redesign your application for cloud-native capabilities, making it scalable and future-ready. Scenario : A monolithic, highly scalable customer-facing application is experiencing performance bottlenecks on-prem. What long-term cloud strategy would you propose?. Beyond these strategies themselves, successful cloud migration also focuses on: - thorough assessment, - understanding dependencies, - meticulous planning, - and continuous optimization Just remember: successful migration isn't just about the tools, but the approach. Very important to understands the "why" behind each strategy — not just the "how." Dropping a newsletter this Thursday with detailed scenario based questions (and example answers) for each of these patterns — subscribe now to get it -> https://lnkd.in/dBNJPv9U • • • If you found this useful.. 🔔 Follow me (Vishakha) for more Cloud & DevOps insights ♻️ Share so others can learn as well

Lift and shift is the most expensive way to avoid real cloud transformation. Moving your mess to the cloud just gives you an expensive mess. At Mayfair IT, we have built cloud platforms using fundamentally different approaches. The difference in outcomes is dramatic. Lift and shift is seductive. Take existing servers, virtualise them, run them in Azure or AWS. Call it cloud migration. Declare victory. The infrastructure is now in the cloud. The problems are unchanged. Applications still assume they run on dedicated hardware. Scaling requires manual intervention. Failures cascade because nothing was designed for distributed failure. You pay cloud prices for on premises architecture. What cloud native actually means, We have built greenfield platforms on Azure designed from the beginning for cloud. Platform as a Service and Software as a Service components doing what they do best. Azure Data Factory orchestrating data pipelines instead of custom ETL running on virtual machines. Cosmos DB providing distributed databases instead of clustered SQL servers. Serverless functions handling event driven workloads instead of always on application servers. The difference is economic and operational. What changes with cloud native architecture: → Scaling happens automatically based on demand, not manual capacity planning → Failures in individual components do not bring down entire services → You pay only for resources actually used, not capacity provisioned for peak load → Updates deploy without downtime because architecture assumes continuous change We have also migrated legacy systems to cloud where complete refactoring was not feasible. The challenge is knowing which approach fits which situation. Greenfield builds should always be cloud native.  Legacy migrations require honest assessment of whether lift and shift provides enough value to justify the effort. Sometimes the answer is yes.  Moving a stable system with known workloads to cloud can reduce operational overhead even without refactoring. But presenting lift and shift as cloud transformation is dishonest.  You moved the location. You did not change the architecture. The organisations getting real cloud value are the ones willing to rebuild applications to use cloud capabilities properly. How much of your cloud spending is on virtualised servers that could be replaced by managed services? #CloudNative #Azure #DigitalTransformation

In 100 days, a SAP SuccessFactors login that works today may stop working. On November 13, 2026, SAP deletes UI Basic Authentication and direct third-party corporate identity provider integration with SAP SuccessFactors. The risky assumption is: “We already use SSO, so we are covered.” SSO is not the architecture answer. The real question is whether your corporate identity provider connects directly to SuccessFactors, or through Identity Authentication in SAP Cloud Identity Services as the proxy IdP. There is also a simple warning sign for Partial Organization SSO: If users can reach the SuccessFactors username and password page and log in successfully, the legacy authentication path is still active. Before the deadline, validate: • Employee authentication • Partial Organization SSO • Administrator and emergency access • Identity provisioning and account mapping • Onboarding and external-user authentication as a separate workstream • Preview, test, and production tenants A successful login today proves only that the current path works. It does not prove that the path will survive November 13. That is a deletion date. Not a planning date.

𝐄𝐧𝐭𝐞𝐫𝐩𝐫𝐢𝐬𝐞 𝐀𝐳𝐮𝐫𝐞 𝐋𝐚𝐧𝐝𝐢𝐧𝐠 𝐙𝐨𝐧𝐞 𝐀𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞 Most enterprises treat Azure like a single subscription. The ones that scale treat it like a multi-region, multi-environment platform with strict boundaries. Here is the landing zone architecture that separates production-ready deployments from chaos: 𝟏. 𝐆𝐥𝐨𝐛𝐚𝐥 𝐋𝐚𝐲𝐞𝐫 • Azure Container Registry stores container images centrally. • Azure Front Door with WAF protects applications at the edge. • Azure Cosmos DB provides globally distributed database access. • Azure Log Analytics and Storage centralize logging and telemetry across all regions. This layer is shared across all regions and environments. 𝟐. 𝐑𝐞𝐠𝐢𝐨𝐧 𝟏 𝐚𝐧𝐝 𝐑𝐞𝐠𝐢𝐨𝐧 𝐧 • Each region is subdivided into Stamps for independent deployment units. • Website hosts the application frontend. • Azure Key Vault secures secrets and credentials. • Azure Event Hubs handles event streaming. • Checkpoints Storage persists processing state. • Azure DNS manages domain resolution. 𝟑. 𝐌𝐚𝐧𝐚𝐠𝐞𝐦𝐞𝐧𝐭 𝐋𝐚𝐲𝐞𝐫 • Self-hosted build agents run CI/CD pipelines. • Jump Boxes provide secure access to private resources. • Azure Bastion enables browser-based SSH and RDP without exposing VMs. • All management traffic runs through vNet. Access is locked down. No direct internet access to production workloads. 𝟒. 𝐂𝐨𝐧𝐧𝐞𝐜𝐭𝐢𝐯𝐢𝐭𝐲 𝐒𝐮𝐛𝐬𝐜𝐫𝐢𝐩𝐭𝐢𝐨𝐧 • Hub VNet in each region connects to spoke VNets via vNet peering. • Azure Firewall, Express Route, and VPN control traffic between on-premises and cloud. • Azure DDoS Standard protects against volumetric attacks. • Role Assignment, Policy Assignment, Network Watcher, and Defender for Cloud enforce compliance and security. This is the central hub that routes all traffic and enforces security policies. 𝟓. 𝐑𝐞𝐠𝐢𝐨𝐧𝐚𝐥 𝐌𝐨𝐧𝐢𝐭𝐨𝐫𝐢𝐧𝐠 • Azure Log Analytics aggregates logs from all resources. • Azure Application Insights tracks application performance. • Storage archives telemetry for long-term analysis. Monitoring is regional but feeds into a global view. 𝟔. 𝐎𝐧-𝐏𝐫𝐞𝐦𝐢𝐬𝐞𝐬 𝐈𝐧𝐭𝐞𝐠𝐫𝐚𝐭𝐢𝐨𝐧 • Express Route or VPN connects on-premises systems to Azure. • Hub VNet bridges cloud and on-premises environments. Landing zones are not optional for enterprise scale. Without them, you get sprawl, security gaps, and inconsistent deployments across regions. 𝐖𝐡𝐢𝐜𝐡 𝐩𝐚𝐫𝐭 𝐨𝐟 𝐲𝐨𝐮𝐫 𝐀𝐳𝐮𝐫𝐞 𝐚𝐫𝐜𝐡𝐢𝐭𝐞𝐜𝐭𝐮𝐫𝐞 𝐧𝐞𝐞𝐝𝐬 𝐭𝐡𝐞 𝐦𝐨𝐬𝐭 𝐚𝐭𝐭𝐞𝐧𝐭𝐢𝐨𝐧? ♻️ Repost this to help your network get started ➕ Follow Anurag(Anu) Karuparti for more PS: If you found this valuable, join my weekly newsletter where I document the real-world journey of AI transformation. ✉️ Free subscription: https://lnkd.in/exc4upeq ##AzureArchitecture #LandingZone #EnterpriseCloud Reference: https://lnkd.in/e3ujruqt

We Migrated 52 Services to Kubernetes. Here are the brutal lessons no one warned us about (but every DevOps team must know before attempting this): 1. 𝐎𝐯𝐞𝐫-𝐄𝐧𝐠𝐢𝐧𝐞𝐞𝐫𝐢𝐧𝐠 𝐭𝐡𝐞 “𝐏𝐞𝐫𝐟𝐞𝐜𝐭” 𝐂𝐥𝐮𝐬𝐭𝐞𝐫 𝐃𝐞𝐬𝐢𝐠𝐧 We spent weeks debating multi-cluster vs. single-cluster, custom CNI plugins, and service meshes. End result? Half the “must-have” features were never used. ☑️ Lesson: Migrate first, optimize later. Complexity will kill momentum. 2. 𝐈𝐠𝐧𝐨𝐫𝐞𝐝 𝐭𝐡𝐞 𝐑𝐞𝐚𝐝𝐢𝐧𝐞𝐬𝐬 𝐨𝐟 𝐃𝐞𝐯𝐞𝐥𝐨𝐩𝐞𝐫𝐬 We assumed dev teams would magically “figure out” Kubernetes. Instead, 30% of deployments failed due to bad YAMLs, incorrect resource limits, and missing health checks. ☑️ Lesson: Train developers before you migrate. Kubernetes is not “just another platform.” 3. 𝐎𝐯𝐞𝐫𝐥𝐨𝐨𝐤𝐞𝐝 𝐂𝐨𝐬𝐭 𝐆𝐨𝐯𝐞𝐫𝐧𝐚𝐧𝐜𝐞 𝐟𝐫𝐨𝐦 𝐃𝐚𝐲 1 We were so focused on “just making it work” that we didn’t enforce quotas or cost limits. One namespace spun up 100+ pods running idle workloads. ☑️ Lesson: Treat FinOps as a Day 0 concern, not a post-migration headache. 4. 𝐃𝐢𝐝𝐧’𝐭 𝐏𝐥𝐚𝐧 𝐟𝐨𝐫 𝐒𝐭𝐚𝐭𝐞𝐟𝐮𝐥 𝐖𝐨𝐫𝐤𝐥𝐨𝐚𝐝𝐬 𝐏𝐫𝐨𝐩𝐞𝐫𝐥𝐲 Moving stateless apps was smooth. Databases? Nightmare. PersistentVolumes misconfigured. Data corruption risks everywhere. ☑️ Lesson: If you’re moving stateful apps, triple-check your storage class, PVC configs, and backup plans. 5. 𝐋𝐚𝐜𝐤𝐞𝐝 𝐂𝐥𝐞𝐚𝐫 𝐒𝐋𝐎𝐬 𝐟𝐨𝐫 𝐌𝐢𝐠𝐫𝐚𝐭𝐢𝐨𝐧 𝐒𝐮𝐜𝐜𝐞𝐬𝐬 We never defined what “success” looked like. Did faster deployments mean success? Cost reduction? Better reliability? ☑️ Lesson: If you can’t measure it, you won’t know when to stop fixing it. Would I do it again? Absolutely. But not without fixing these five things first. If you’re planning a migration soon, ask yourself: Are you solving real problems, or just building a shiny new platform nobody knows how to use? ♻️ 𝐑𝐄𝐏𝐎𝐒𝐓 𝐒𝐨 𝐎𝐭𝐡𝐞𝐫𝐬 𝐂𝐚𝐧 𝐋𝐞𝐚𝐫𝐧.

While auditing an EU FinTech scale-up, I came across some surprising design choices: • Flat subscription sprawl • No Azure Policy enforcement • No Hub-and-Spoke network model • No Management Group hierarchy Clearly, they had grown fast but without structure. So I led a Landing Zone redesign based on Microsoft’s Cloud Adoption Framework and deployed: 👉🏻A Core Infrastructure Management Group with Policy-as-Code 👉🏻Spoke separation by app and environment 👉🏻Role-based access controls aligned with team structure So The result is 94% policy compliance in just 6 weeks & Clear cost ownership per team & A secure, scalable foundation ready for future growth Without Landing Zones, your Azure setup is just an expensive sandbox. #AzureCAF #EnterpriseLandingZone #ArchitectureReview #InfraGovernance #AzureBestPractices #CloudStrategy

Colgate-Palmolive ran everything through SAP - from factory floors to dentist offices. When I led their migration, one thing was clear: this wasn’t just about moving systems. It was about keeping a global supply chain alive. Back in the early 2000s, I was consulting on one of the most high-stakes SAP migrations I’d ever faced. Colgate’s global operations depended on a single truth: If SAP goes down, so does everything else. Toothpaste doesn’t show up on shelves. Distribution centers stall. Orders to Walmart, Walgreens, and CVS? Delayed. The supply chain goes silent. I remember thinking, “This isn’t about software anymore. This is a logistics problem with a technical disguise.” So before we moved a single bit of data, we did what most teams skip. Here’s what our playbook looked like: 1. Inventory the unknowns We scanned every system — not just for size, but interdependencies. You can’t move System A if B, C, and D are chained to it. 2. Model the risk How much data? How long would each copy take? Where were the bottlenecks — disk IO, network bandwidth, or just legacy bloat? 3. Rank criticality by impact, not size Some “small” systems had outsized business value. Like the one tracking global SKUs. Touch that wrong, and orders get lost in translation. 4. Simulate the move — multiple times We did dry runs. Timed every process. Tweaked our scripts. Even ran scenarios for “What if this breaks mid-flight?” 5. Coordinate like air traffic control Every migration phase was mapped like a flight plan. Timelines, dependencies, failovers. No guesswork. No egos. That project worked. No disruptions. No delays. No headlines (which, in IT, is a win). It also planted the seed for what would eventually become IT-Conductor Inc. Because I realized: Migrations aren’t about tools or timelines. They’re about orchestration. And orchestration starts with a brutally honest assessment. If you're facing a cloud migration and feel unsure where to start — start there. That’s what separates a clean cutover from a career-defining disaster.

On prem to Cloud migration Step-by-Step AWS Cloud Migration Process 1. Plan the Migration Assessment: Identify the current environment (servers, databases, dependencies, and configurations). Inventory: Document application components and dependencies. Sizing: Determine AWS resources (EC2 instance types, RDS configurations, etc.) based on current usage. Network Design: Plan VPC setup, subnets, security groups, and connectivity. Backup Plan: Create a fallback plan for any issues during migration. 2. Prepare the AWS Environment VPC Setup: Create a VPC with subnets across multiple Availability Zones (AZs). Security: Configure security groups, IAM roles, and policies. Database Configuration: Set up an Amazon RDS instance or EC2-based database for the migration. AD Server: Use AWS Managed Microsoft AD or deploy your AD on EC2. Application Server: Launch EC2 instances and configure the operating system and required dependencies. 3. Migrate Database Backup: Create a backup of the current database. Export/Import: Use database migration tools (e.g., AWS DMS or native database tools) to migrate data to the AWS database. Replication: Set up database replication for real-time sync with the on-prem database. Validation: Verify data consistency and integrity post-migration. 4. Migrate Application Server Packaging: Package the application (e.g., as Docker containers, AMIs, or simple binaries). Deployment: Deploy the application on AWS EC2 instances or use AWS Elastic Beanstalk. DNS Configuration: Update DNS records to point to the AWS environment. 5. Migrate Active Directory (AD) Replication: Create a replica of the on-prem AD in AWS using the AD Trust setup. DNS Sync: Sync DNS entries between on-prem and AWS environments. Validation: Test authentication and resource access. 6. Test and Validate End-to-End Testing: Validate the complete environment (application, database, and AD). Performance Check: Monitor performance using CloudWatch and address any issues. Failover Testing: Simulate failure scenarios to ensure HA/DR readiness. 7. Cutover and Go Live Schedule Downtime: Coordinate with stakeholders and users for a minimal downtime window. Final Sync: Perform a final sync of the database and switch traffic to AWS. DNS Propagation: Update DNS settings to route traffic to the AWS environment (may take up to 24 hours). Monitoring: Continuously monitor AWS resources and performance post-migration. 8. Post-Migration Optimization Scaling: Implement auto-scaling policies for the application. Security: Regularly review and improve security configurations. Cost Optimization: Use AWS Cost Explorer to analyze and optimize resource usage. Downtime Considerations Database Migration: Plan a maintenance window of 2–4 hours for the final database sync and cutover. DNS Propagation: Approx. 15 minutes to 24 hours, depending on TTL settings. Use short TTLs during migration to minimize delays. #AWSMigration #CloudMigration #MinimalDowntime #DatabaseToAWS #ApplicationToAWS #ADToAWS

📌 How to Build Your Azure Landing Zone for Scaling Cloud Environments Securely A well-architected landing zone separates responsibilities across management groups and subscriptions, enforces policy and security controls by default, and supports growth across teams, regions, and lifecycles. ❶ Tenant-Level Architecture ◆ Use Microsoft Entra ID as the central identity plane for users, groups, service principals, and role assignments. ◆ Apply PIM and Conditional Access across all admin roles. ◆ Connect on-prem identities with Active Directory Domain Services when hybrid is needed. ❷ Management Group Hierarchy ◆ Start with a clear tenant root group, structured by platform functions (Security, Management, Connectivity, Identity) and LZ (Corp, Online, Sandbox). ◆ Apply guardrails at the group level using Azure Policy, RBAC, and budget alerts. ◆ Assign subscriptions below groups to enforce separation of concerns. ❸ Subscription Separation of Duties ◆ Security Subscription: Centralize logging, Defender for Cloud, and policy enforcement. ◆ Management Subscription: Central dashboards, cost tracking, log collection, and updates. ◆ Identity Subscription: Host DCs, Microsoft Entra DS, and recovery services. ◆ Connectivity Subscription: ExpressRoute, DNS, Firewalls, and VNet peering. ◆ LZ: Host production workloads (P1, A2) with consistent network, identity, and backup setup. ◆ Sandbox Subscriptions: Isolated for dev/test with limited permissions and spending controls. ❹ Network Topology & Peering ◆ Use hub-and-spoke architecture with VNets per region and peering to a shared connectivity subscription. ◆ Centralize inspection using Azure Firewall, Route Tables, and NSGs/ASGs. ◆ Secure DNS resolution with Private DNS Zones and on-prem forwarding if needed. ❺ Platform Automation & GitOps ◆ Manage all infra as code using a central Git repository. ◆ Store definitions for roles, policies, blueprints, Bicep modules, and templates. ◆ Automate provisioning via pipelines (e.g., GitHub Actions, Azure DevOps) for repeatability and traceability. ❻ Logging, Monitoring & Compliance ◆ Send logs from all subscriptions to Log Analytics in the Security sub. ◆ Use Azure Monitor for platform-wide observability. ◆ Set up Update Manager, Defender for Cloud, and cost alerts centrally. ❼ Cost Management & Policy Enforcement ◆ Apply cost management and Azure Policy consistently across subscriptions. ◆ Use budget alerts and tagging to track usage per environment or team. ◆ Prevent misconfiguration with deny assignments and policy enforcement at the platform layer. ❽ Landing Zone Blueprint Implementation ◆ Define compliant VM SKUs, network configuration, backup strategy, and baseline tags. ◆ Ensure shared services like Key Vault, Backup Vaults, and Azure Automation are pre-integrated. ◆ Enforce diagnostics, identity assignment, and Defender onboarding by default. #cloud #security #azure