Good candidates for migration

- [Instructor] Okay, let's talk about selecting workloads for migration. This is probably the most important thing you'll do because the applications and the datasets that are on your current traditional systems, they have to have certain attributes to move into the public cloud. And some of them are going to be able to move very easily with very few changes, if any, some are going to need to be refactored or basically rebuilt for the public cloud, so you're migrating there or a private cloud, and some of them can't move because there's some kind of economic or technology issue that's in the way, or they're just not a good candidate to move in the cloud.

So this is probably one of the most important steps that you'll go through in migrating into the cloud. So applications consist of applications bound with data. So you have to understand that when I talk about workloads and I talk about applications, I'm typically talking about a big pile of source code and big database or some sort of datastore set that comes along with that, and those are typically going to be the workloads. That's what we're moving into the cloud. So we have to deal with them as single components. We're dealing with very complex technological solutions. They have a database, it could be Oracle, it could be something else.

And they have some sort of a code base. It could be Java, it could be Python, it could be something else. The biggest factors are security, compliance, and enabling technology used for the application. So we have to understand what the security requirements are, what the compliance requirements are, and what enabling technology was leveraged. If we're dealing with an old Cobol DB2 system, that typically may not be a good candidate for the cloud because we just don't have a platform analog that exists in the public cloud yet. However, if we're dealing with a Python or LAMP stack, which is Linux, Apache, MySQL, Python, there's definitely going to be analog in the public cloud.

So we deal with workbenches typically. We leverage the portfolio application assessment for migration to ensure that each application being migrated is assigned to one of six different categories. So when we do an application portfolio assessment, we look at every application workload that exists within the Global 2000. And that could be between 2,000 on the low end to 5,000 on the high end, and I've seen every number in between. And with the migration workbenches, we basically put them into one of one, two, three, four, five buckets. Either rehost, in other words we're moving them to a new platform, we're replatforming them.

In other words, we're not only just moving them to a new public cloud provider, but we're putting them on a new platform within the public cloud provider. For example, we could be on LAMP stack in the traditional system and we could be moving it to Windows in the target platform on the public cloud. We may refactor the application, in other words, we're going to rewrite significant portions of it to take advantage of the public cloud or take advantage of the cloud provider, public or private that we're moving it to. We could rewrite the whole thing from the ground up. In other words, we're throwing away the code and throwing away the database typically, and we're redoing the code from the ground up, probably the most expensive, most risky thing that's done, but a lot of people have applications.

They want those things to live in the public cloud or private cloud, and they're willing to endure the cost of rewriting the entire application. We may replace the application, we may use SaaS equivalent, such as Salesforce.com, or we may retire the application entirely, and we see a lot of this. Probably 10 to 20% of the applications, as we're looking at them to migrate into the cloud, are just simply retired. We do away with them. We may find a SaaS platform that is comparable, or we may rewrite in that new application. So good candidates are applications built in the last 10 years using more contemporary technology.

So we talked about LAMP stack and Java, and those sorts of things. We know that technology well, and there's definitely platform analogs that exist in private and public clouds that can run those things without a significant amount of modification or no modification. Applications that are decoupled from the database. Applications that have lower-security requirements, albeit changing. In order words so we may not need high-end security that exists in the public cloud, but if there is high-end security, there may be some perimeter issue that is associated with the data, in other words it can't leave our data center, for some particular reason, either it's compliance, security, things like that.

So usually lower-security applications are typically what people pick for a public cloud and private cloud, however, we're at a point where private cloud security is just as good, if not better, than traditional security that exists within the enterprises. Applications that have a lower number of compliance issues, in other words, we don't have to deal with laws and legal issues that deal with how data is audited, maintained, and stored on a public cloud. However, you should know if you're doing HIPAA and PCI, there are those capabilities, those services, within the public cloud providers you're able to leverage now.

But if there's lots of compliance issues, sometimes it just basically decreases the value in relocating that application to the public cloud. Applications that are well understood by IT typically are good candidates. In other words, we have something we work with all the time, it's well maintained, we have people around who know it, and therefore moving it into the cloud won't be that much of a challenge. If we're dealing with an old application where not too many people know, or probably nobody knows it, that's going to be a bit of a challenge in moving into the cloud because we're going to discover issues as we go ahead and make the migration. So successful cloud engagements, cloud first team established, focused, ring-fenced team, funded and dedicated.

So in other words, we have a team that they're just doing the migration. Assessment, we do them now, application portfolio assessment, security cloud assessment, cloud economic assessment, we talked about that in a previous video. Iterate your plan, cloud adoption plan, fail fast. So in other words, as you move through your plan, make sure you make all the mistakes as quickly as you need to make them so you can basically correct the direction that you're moving into, and the agile model is critical here. So we're dealing with DevOps. We're dealing with agile-based systems. We're not typically doing this using traditional approaches.