Transitioning Applications To The Cloud

I once watched two engineers try to run three SAP migrations in one weekend. Manually. Burnout. Missed steps. Overruns. Same team, next project: We gave them orchestration tools and a conductor mindset. They finished early and slept. That story from 25 years ago still happens today. I've been involved in over 1,000 system migrations. The technology changed. The platforms evolved. Cloud became the destination. But the core problem remains the same: Most migrations still run on spreadsheets and screenshots. What I see happening: Customer wants to migrate to cloud. Three system integrators bid for the assessment. Each one asks for the same inventory documents. Performance reports. Connection diagrams. They take this static data back to their teams. Spend weeks analyzing PDFs. Come back with proposals. But by the time they present to management, the customer already rolled out new features. Added 20% more users. Database grew 30%. The data they analyzed is stale. So what happens next? Lawyers write disclaimer pages. "Any changes require a change order." Corners get cut. T-shirt sizing replaces precision. The migration starts with outdated assumptions. I've seen hypercare periods stretch from 3 days to 2 weeks because nobody had baseline data to debug issues. There's a better way. Instead of paper-based assessments, create a live data room. Connected systems. Real-time metrics. Automated collection. When something changes, everyone sees it immediately. No more guessing. No more stale proposals. No more "I thought I told you about that system." You wouldn't hire a contractor to remodel your house using six-month-old blueprints. So why migrate business-critical systems using outdated data? The most successful migrations I've seen follow this pattern: 1) Live data collection from day one 2) Automated assessment updates 3) Orchestrated execution with minimal manual work The engineers sleep. The systems work. The business runs. Better to have too much data than not enough. That's my rule for migration data. Because when your entire business runs through SAP, you can't afford to guess.

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

When I was CIO at Microsoft, I led our efforts to move our internal applications to what became Azure. Here’s the framework I use to decide what moves to the cloud. I found there are three categories of applications, and this is still generally true today. 1. Modern, cloud-ready applications. These were basically designed for the cloud because they were created using modern virtualization operating models and modern cloud-ready toolsets. You can move them from your own data center pretty quickly if you choose to. As an early adopter of virtualization, we had a few of these all ready to go. And, any new development was targeted for the cloud as a default. 2. Applications that needed to be substantially re-architected to be cloud-ready, or could be replaced entirely with a SaaS offering. For these applications, we generally decided to replace them with a SaaS offering. More importantly, we set a time frame for a decision on these applications with the goal of eliminating all of the old apps that did not meet our cloud-ready criteria. For example, many companies historically built their own HR applications or marketing apps. Today, you would just use a SaaS offering from one of many potential SaaS vendors. It shocked me to discover how many of these internal applications had been built over time, and how quickly most of the business capability could be replaced with a SaaS offering. 3. Applications you're stuck with. They just work, but they aren't architected for modern cloud environments, and you can't do anything with them to modernize in a reasonable amount of time or other things are higher priority. You're probably going to keep these in your own data center in a virtualized environment, which is exactly what we did. If you're a CIO of any really large organization, you're likely going to have some core on-prem data center applications. But the majority of your applications will likely be running in a combination of public cloud, private cloud, and commercial software as a service. In my mind, it's probably two-thirds or three-fifths cloud, and a third to two-fifths private. It will vary depending on the business you're in and how regulated you are. But the most important thing is to regularly evaluate these technology decisions against the business context and actively optimize the application portfolio to suit the strategy of the organization.