Hardware and software migration projects are like crack for IT executives. Especially when the number on the new invoice is smaller than the number on the old invoice. Even better when the products can be folded into a previously negotiated enterprise agreement and made to appear free. Add to that an audience with the vendor company’s CEO, a keynote at the annual conference along with a VIP backstage meet-and-greet with the top-40 80’s rock band playing for the gala, and a seat on the executive advisory board. This deal is awesome! My job here is finished. Now you go get rid of all that old legacy stuff and replace it with this new modern stuff. It shouldn’t take very long. After all, you’re already familiar with the data and the reports and the applications and everything.
Sound familiar?
Migration projects fall into two categories: those that you want to do and those that you are told to do.
A migration that you want to do is exciting. It’s typically motivated by problems you’re having with the current system that the new system promises to solve. Probably some combination of performance, reliability, features, and functionality. The driving force for change is usually the user community and/or system team, and they know that something better is waiting on the other side. The benefits are well articulated and quantified, and it is often management that has to be convinced to support the project.
A migration that you are told to do can be agonizing. It’s typically motivated by factors that have nothing to do with solving business problems or generating business value. Instead, it’s usually cost, standardization (another word for cost), corporate strategy, and/or politics. The driving force for change is management. Benefits beyond a smaller check written to the vendor are rarely identified, and the real migration costs are rarely considered. And after all that, you hope that when you’re finished you and your users can still do what you all are doing today.
One potential exception is a migration that is the result of a broader corporate cloud strategy, where on-premises and client-based tools are replaced with equivalent cloud-based offerings. Yes, it’s a lift-and-shift, but this approach satisfies the cloud mandate in the least amount of time and the least impact to the users. Plus, when you’re finished you have the benefits of cloud resource availability and you can begin to expand your capability portfolio. (As an aside, we’re starting to see companies that started with a broad mandate to move everything into the cloud now backtracking because of cloud sticker shock, reverting to a hybrid solution that includes stand-alone data centers, cloud, and/or colocation facilities.)
Begin with a clear and honest answer to the question: Why are we doing the migration?
Consider whether or not, when you finish the migration, you expect to have: more capabilities, better performance, higher availability, less complexity, tighter integration, smoother workflows, easier manageability, and/or lower price. How many can you answer affirmatively? If sticker price is the sole motivation, then probably not many. Maybe just the one. When management is confronted with the adverse impact to the environment and to the users, even at this level of granularity, they may reconsider their mandate and look for a more beneficial alternative.
The point of evaluating these factors is to ensure that the true cost (or benefit) of the migration is considered before starting down that path. Invoice price might be the most obvious and easiest to calculate, but it is not the most important and is not, in general, the most significant. Unfortunately, most other factors are ignored in the decision-making process. Then we have the nerve to wonder why our company isn’t producing innovations or business value very fast.
So, the first thing you have to recognize is that:
A migration project is time-out from business value delivery; like a pit stop where parts are swapped out with the expectation of better subsequent performance.
Everybody will be very busy, but no incremental business benefit will be generated. To recoup the cost of the migration, business benefit generation must accelerate when the migration is finished. If you answered ‘no’ to more than a couple of the factors above, then you are not likely to recoup the migration cost.
Think about your migration project like running a marathon in rented shoes. (I know, I know. It’s not a photo-realistic example, but stick with me. You’ll get the point.) You start out with some good shoes, but they’re very expensive. Comfortable and well-fitting, but expensive. At, say, the ten-mile marker you have the opportunity to swap out your shoes. The ones you have are expensive and you don’t want to keep spending the money. Besides, you’re doing fine. So, you stop, select a less expensive pair, and put them on. All the while you’re not making any progress toward the finish line. You’re betting on the expectation that you’ll make up the lost time by running the remainder of the race faster. The shoes are cheaper, but they don’t fit as well and after a few miles your feet begin to hurt. Your pace slows considerably. You finish the race. Eventually. Far short of your goal, blood soaking through your socks, and far slower than had you not migrated. As you hobble back home with your disappointing result, you can console yourself with the money you saved as you try to convince yourself that it was worth it.
Before launching a migration project, it’s important to account for all of the costs; those that are obvious and those less so. In Part 2, we’ll look more closely at some of the factors to consider when evaluating the actual cost of a migration project.
1 Comment
Kevin Mireles · August 21, 2024 at 5:55 pm
Nice post. Obviously, none of this from firsthand experience. 🙄
Love the analogies, and so much truth to the slowing down to get back to where you were.
Comments are closed.