My Amazon author page!!!!

There is an upcoming cloud computing introduction course available from IASA Education. In that course we will talk about pricing and other cloud concepts from both the technical and business viewpoint. Today’s blog focuses on the broad concept of cloud migration buckets.

Anyone who walks into your office and tells you migrations are easy is lying to you. Let’s start with that as a baseline. Migrations run into issues. I’ve done a large number of migrations over the years and even the perfectly planned migration has issues in the end.

So let’s start instead with the broader concept “migrations will have issues” our goal is to approach the migration with the best possible risk mitigation plan.

Or to steal from popular media let’s create a bucket list.

If you think about migrations from two views the first business and the second being technical there are things that are quickly revealed.

  1. There are applications that make money.
  2. There are applications that support the making of money.
  3. There are applications that support the supporting applications.
  4. There are applications that neither support the supporting or in then end make money.

Any application in bucket 1 should be treated differently than applications in bucket four. It’s a given – if you aren’t making money with the application then take a long hard look at why you are even considering migrating it.

During migration planning a CIO once grabbed my arm and said “you’ve marked a lot of applications as do not migrate.” My answer was simply “no one has used them in more than two years. I don’t think they are business relevant anymore.”

So the initial list we create will cull a set of applications from your overall portfolio. Applications we no longer use. For applications that fit into buckets two and three take a long look at them. What are they in the end providing to your organization? In building a portfolio of capabilities for your organization it is important to evaluate the reality of mixed bag capabilities. If you have more than two ways to solve a specific business problem you can probably look at them and come up with only one way to do that going forward.

That initial portfolio that aligns what you have (capabilities) against what the business uses (1-3) results in a high level functional application portfolio. To solve the reality issue (too many ways to solve a problem) you then can map this list against the capabilities listing of your enterprise architecture.

Once you have that list created – its time to make your bucket list.

There are three buckets for applications in the enterprise when we consider migrations.

  • Applications that do not require any work or effort and can be migrated (with minor tweaking) today.
  • Applications that require some work but not extensive. Extensive is determined by the business. The cost of a migration cannot exceed the capability of the solution. IE if you make 3 dollars from an application every month after cost – and it costs 12 dollars to migration then that is a safe migration. If it costs 24 dollars to migration then you have to consider the migration of that solution as is. (where in both cases the dollar amount refers to the cost of migration – redevelopment, data transport etc).
  • Applications that require extensive work. So these are the applications that stretch beyond the overall business goal – ROI/TCO and specific timeframe for the ROI. If you migration goal is to complete the payback in 24 months. Applications that cannot repay the overall migration costs should be considered heavily. Do you rewrite the application? Do you drop that capability from the portfolio or in the end do you buy a newer version of that capability and leave your old data in your on-premise data store?

There is more to come in this series…


Scott Andersen

IASA Fellow