A structured approach for migrating to cloud!

You’re a big bank with decades of investment in technologies that once where cutting edge but now are slowing you down and are costly to maintain. You know public cloud is the way to go and you have chosen your favorite – AWS, Azure or GCP but how do you migrate in line with your business objectives, move away from your data centers and manage complexities of not just technologies but people and processes as well? What are the biggest challenges? How do you overcome them? Here is my take on some of the most important ones.

‘As Is’ Assessment

Once you have established the business benefits you want to get from your move to the public cloud – agility, scale or cost reduction, the first step is to assess which workloads you move and in which order. When you look at assess what you’ve in your data center, it’s important to look at not just the business benefits but feasibility and dependencies among business processes. What all things need to move to the cloud “together” to form a unit that delivers that promised business value? The answer will typically go across multiple layers of your technology stack including data storage, computer and orchestration and will need to take into account criticality of application and sensitivity of data.

All major cloud providers have tools to help you with discovery and assessment activities. That is step one.

Defining Target

Once you know what you want to move to the cloud, the question is how. Do you just want to ‘lift and shift’ what you have in your data center with a slightly managed flavor of cloud service because that’s the safest thing to do? Or, do you want to embrace cloud native, change your technology stack, break down monolith into micro-services and make your architecture more future proof?

While it may be tempting for the banks to be risk averse and lift and shift, by doing it you may negate many of the benefits the cloud offers.

For each workload, being clearer on the target helps. A potential approach could be a multi-step one. You start with lift and shift to accelerate your migration and you commit to follow it up with cloud native and server-less approaches.

Moreover, taking a patterns-based approach also helps ‘build once, use many’ benefits.

Building Cloud Foundation

As soon as you have established the targets on paper and started planning migration, you realize that for you to migrate your application you need tons of foundational components – from identity and access management, security perimeters, networking controls, logging, monitoring, cost controls and the list goes on.

Investing in building Landing Zone for your chosen cloud with all regulatory and security controls early on goes a long way in accelerating application migration and modernization. The landing zone should take a holistic view of all platform resources that are required to support the application portfolio.

Migrating, Testing and Optimizing

You’ve picked up the application in line with business priorities. You have defined a target – whether it’s lift and shift or cloud native. You’ve built a strong foundational landing zone to support your migration. You’ve defined patterns (and POCed them). What’s next? To do it.

You start build for the target – all layers of the technology – storage, compute to orchestration in line with the patterns you defined. You migrate your data, you code, you test it - including performance and reconciliation with a parallel run. You put together a cut over plan.

Your application is working now with a lot more managed cloud services but are you getting all the benefits you were promised? Maybe or maybe not, that’s when optimizing becomes important – whether it’s the size of the compute or configurations for data storage or costs – you’ll need to make many tweaks before you get the full benefits of the cloud.

Summary

Cloud is the present, cloud is the future but you do need to follow a structured approach for migration to get all the benefits.