What do I mean by workload migration?
We hear about workload migration all the time, particularly as businesses continue to look towards the public cloud for agility, elasticity and other benefits, whether real or imagined.
When I refer to workload migration, there are many potential interpretations. So I could mean any of the below – or even something I’ve missed:
- Changing the operating system a workload is running on
- Changing the application that provides the workload
- Transforming the workload (e.g., from Mainframe to Midrange, or Midrange to Cloud-Native)
- Moving the workload from on-premises to the cloud
- Moving the workload between clouds
- Moving the workload from the cloud to on-premises
- Adopting an entirely new workload (i.e., migrating from nothing, to something)
Workload Migration Depends on Business/IT Maturity
Let’s start by addressing the elephant in the room: not every business or IT department has the same level of maturity. This is not even reflective of traditional vs cloud-native businesses; maturity comes from the application of intent, not where you operate.
Maturity is also not about whether you do things fast or slow. You can be mature and agile – and you can also be slow and immature. Again, maturity comes from the application of intent, regardless of how fast you do it.
When I first got into data protection in the 90s, it was depressingly common to see entire projects or solutions deployed where data protection was an afterthought. It kind of went like this:
Business: “Let’s put in a new system ‘X’!”
{business spends millions, almost exhausting project budget and getting to 95% complete}
Someone in the business: “Oops! We didn’t think about backup. You! Give us your cheapest option!”
Someone in data protection land: “It will cost you $100 to protect this workload.”
Business: “Outrageous! We only have 10c left in our multi-million-dollar budget and here you are trying to gouge us with some gold-plated $100 thing you say is your lowest price/cheapest option! We demand a 5c option AND the SLA’s appropriate to this new mission-critical application!”
I’m not exaggerating too much. I almost left the industry in despair about this lack of maturity. But even today, not all businesses and IT departments approach everything with an appropriate level of maturity.
To approach a workload migration with an appropriate level of maturity, you have to consider three decision domains:
- How the migration affects the business
- How the migration affects IT
- How the migration affects data protection
Remember the old mantra, “Fast, cheap, good — choose two”? That’s not good enough here; you have to consider all three decision domains, or you’ll get it wrong.
Decision Domain: The Business
In a lot of senses, the decision domain around the business is the easiest. It really only covers two essential questions:
- What benefit do we get in general?
- What benefit do we get compared to the current state?
Both of the above questions can encapsulate a lot of data, including cost, revenue, risk, and so on. So they’re nuanced questions for sure, but they capture the heart of it.
If you can answer both in a way that yields a net-positive result, you’re covered for the business decision domain. The net-positive is important: one question might be answered without benefit, or even a negative result, so long as it’s balanced out by the other. For example, the general impact of implementing a new accounting platform might result in the need to hire additional staff and slow down processing by 5% for at least 12 months. But if the current state fails to pass an audit and leaves the company exposed to regulators, maybe it’s still the right move compared to staying with the status quo.
Decision Domain: IT
IT starts to get a little more complicated. There’s only one core question, but it has to be asked three times with different audiences in mind. So you have to work out the answer to the question, how does this change our processes? for each of the following three situations:
- Front-facing, to the business
- Side-facing, to other teams in IT
- Inward-facing, to the “us” in workload administration.
Each audience question will have one or more answers that can be deemed good, neutral or bad results in changes. The resulting answers in terms of changes may not be net-positive, though! Ideally, you’d want them to be net-positive, of course, but if the business requires a workload change that will radically improve its stance in the marketplace, that may come with increased stresses on the IT department. The important factor here is to map those details out.
I’ve not included data protection in IT for one simple reason: it spans business and IT. IT may have to implement it, but the business owns it, and that’s why data protection has its own decision domain.
Decision Domain: Data Protection
Before I go too much further, let’s acknowledge once again that “data protection” means different things to different people. From my perspective, there are three fundamental pillars of data protection being:
- Security
- Privacy
- Preservation
Most of what I do is data protection related to preservation: backup and recovery, snapshots, replication, CDP, fault tolerance – all those good things. But a modern business has to treat all three with the utmost seriousness.
We see examples of businesses that failed to consider the security and privacy implications of workload migrations on a near-daily basis. Buckets containing customer-sensitive data left insecure, NoSQL databases openly accessible, sensitive data and keys exposed in source code – the list goes on.
So making sure you can still meet your security and privacy obligations when you migrate or take on new workloads is pretty important. Whether or not this is adequately considered really does speak to the heart of business/IT maturity.
However, preservation activities – i.e., the full FARR model (Fault tolerance, Availability, Redundancy and Recoverability) is part of the data protection decision domain. Or should be! This is where otherwise mature business/IT departments still fall over.
For the preservation aspect, we must consider several questions for mature workload migration approaches. These are:
- How do our SLAs shift?
- Where can we offer better SLAs?
- Where are we unable to meet current SLAs? If we’re unable to meet current SLAs:
- Does the SLA become invalid in the new worload location,
- Can the business compromise on the SLA to adapt as the workload migrates, or
- Does the inability to meet our SLAs make the risk unacceptable?
- How do we preserve/protect our data?
- Quickly,
- Efficiently,
- Cheaply
- How do we egress our data?
- Quickly,
- Efficiently,
- Cheaply
- Can we influence the new platform vendor?
These questions are just as important as security and privacy! And there are two key reasons for this:
- If you can’t sufficiently protect a workload, why are you deploying it?
- If the new workload/workload platform is only cheap until you add in all the comparable data protection you’re doing on the existing platform … it’s not cheap at all.
It’s Not a Mature Decision without All Three Decision Domains
So here we get to the crux of it: you can’t have a mature, reliable workload migration/adoption experience without a considered approach on all three decision domains. Yes, you have to know the business outcomes and the IT impacts, but if you don’t know the data protection changes, the decision is incomplete.