hybrid-cloud-migration

A Quick Detailed Look Into Cloud Migration And Hybrid Cloud

When you begin looking into how to modernize your existing infrastructure you might be thinking how do I move my existing business applications from my current infrastructure into a cloud foundation.

Okay, let’s spend some time talking about hybrid cloud and application migration.

So we’re gonna tell you where to begin the application migration process, how do you assess your applications, then where to keep learning, where to begin. 

So you need to do an application portfolio assessment and that’s basically looking at the workloads that exist within your existing as-is state, or typically your traditional non-cloud systems, and look at the readiness of that portfolio to move into a hybrid cloud. 

What are those applications written for and how easy is it to find platform analogs or programming language analogs that exist on either the private or public cloud.

Your ability to in essence move those applications in a timely and cost-effective way will rely on the need to do a cloud reference architecture. In other words where we’re moving to what that cloud looks like and how we’re going to reference the logical and physical architecture. Then we need to do an application cloud roadmap and plans.

Once we’ve done the assessment, we understand what applications are there and we’ve done the triage in terms of what those application workloads do. Then we put a roadmap in place in terms of which ones need to go first, which one should go, which ones need to be refactored, which ones need to be reposted which ones are going to be cost-ineffective to move. Which means they shouldn’t move and which ones are going to provide the best value to the business. Therefore they should be moved first. 

Then we do the application migration, we have proof of concepts and pilots, we do infrastructure automation. So we automate the operations and deployment of the applications and then application migration and DevOps and how DevOps felts fit into the plan.

So once we’ve migrated the applications to the hybrid cloud how that’s going to be part of a DevOps plan and how those things are going to be matured and developed and tested and automated and operated using a continuous and continuously improving infrastructure. Using agile methodology scrums, use those sorts of things to ensure that we’re basically reacting to the business in terms of the needs were able to

change those applications to meet the needs of the business as quickly as possible.

The application migration process 

The ability to kind of migrate those systems to the hybrid cloud either public or private clouds within the hybrid cloud ecosystem. How DevOps fits in and does the plan for that then also cloud ops. How we plan on operating the system and then back to strategy and economics. and this is basically an iterative process. 

We’re always going to go back to the business case doing security and governance application portfolio assessment application migration DevOps.

And cloud ops until we’ve gone through all of the application workloads and we migrated the ones they’re going to be the most cost-effective and providing those

the most value to the business. But we know what they are, we know where they should exist and we’ve optimized the platforms are going to run on either a hybrid cloud, private or public or traditional, leaving them on the traditional system are moving to. 

And move them to another system or another platform okay let’s look at the process of assessing the applications so in the world of application migration we have an application portfolio assessment process and that’s where we look at the existing systems and we determine exactly what directions those systems need to move into. 

We have a couple of choices. We have a web hosting or lift and shift, we have to Reap forming or basically moving from one platform to another with minor modifications refactoring which means major modifications but typically not a complete rewrite then rewriting the application. Basically bringing it down to its functional primitive and rewriting it from scratch and there’s also replacement.

The ability to find a software-as-a-service analog. for example to replace a human resource system versus building it yourself or outright retirements of the application.

we’re basically we’re just shutting them down because they have no functional use.

Add a Comment

Your email address will not be published. Required fields are marked *