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 seat on the executive advisory board, and a keynote at the annual conference along with a VIP backstage meet-and-greet with the top-40 ’80s rock band playing for the gala. 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 environment that the new one promises to solve. Probably some combination of performance, reliability, manageability, 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.

So, to migrate or not to migrate. You might not have a choice, but at a minimum you need to know where you stand:

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 they have the nerve to wonder why their company isn’t producing data and analytics innovations or business value very fast. 

A migration project is like a time-out from business value delivery; 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 10-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, the clock is ticking and 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.

Migration projects are not going to change the business. They’re not going to run the business either. They’re a full stop, with the expectation that progress will be faster when it’s finished.

The objective is to offset the ground lost during the migration with the ground gained afterward. Therefore, before launching a migration project, it’s important to account for all of the cost factors – those that are obvious and those less so. Only then can the advisability of the migration project be objectively evaluated. 

—

Four different categories of costs, or cost pools to borrow from activity-based costing, collectively contribute to the overall migration cost: invoice, capability, movement, and business benefit. The number on the invoice is just one factor. In many cases, it is the least significant. 

Each expected going-forward cost is compared to the current cost to get the difference or delta. If that value is negative, then the cost is expected to decline over time. If it’s positive, then the cost is expected to increase. The total cost can therefore be expressed as:

Δ Cost (Total) = Δ Cost (Invoice) + Δ Cost (Capability) + Δ Cost (Movement) + Δ Cost (Business Benefit)

Let’s look more closely at the main components, or cost factors, associated with each.

Δ Cost (Invoice)

Oh, the lies that we tell ourselves. The biggest one is that the only thing we need to consider is the number on the bill from the vendor. It’s certainly the most obvious cost factor. It’s also the easiest to compare. Here’s the number from last year. Here’s the smaller number on the quote. Decision made.

Before signing on the dotted line, or even selling to others in the company the amazing deal that’s on the table, consider a few factors:

Promotional Pricing: It’s a common sales tactic. Offer something at a low, low introductory price. Get the customer to buy it, and more importantly get them accustomed to having it. Then, after the trial period, increase the price. Think “get your first month free with a one-year subscription.” 

Colleagues have shared cautionary tales of offers of “all you can eat” software for the first year of a contract, only to have to pay for more licenses than expected in years two and three. Whenever considering promotional pricing, be realistic about the magnitude of the “free” software adoption and the impact of those licenses on the pricing in subsequent years. 

Utilization Assumptions: Pricing and budgeting are predicated on a set of assumptions about how the software will be used. Will those employing the tools use them in the way that you expect? Were those assumptions developed in consultation with the user community, or were they developed in consultation with a calculator and a spreadsheet? How realistic are the utilization expectations? Imagine a scenario where a single BI tool is being replaced with a suite of several tools, each with its own niche: one for querying and reporting, another for visualization, and a third for AI and advanced analytics. Baked into the price offered was the assumption that most users would access the simple reporting tool, fewer would use the visualization tool, and just a couple would need the AI and advanced analytics tool. But ask yourself how much you are counting on the users optimizing their own tool selection to achieve cost savings. If you’re counting on that at all, you’re likely to be disappointed. Most users will take the path of least resistance, learn a single tool, and apply it to as many of their use cases as possible. Even if it’s not the most efficient or cost-effective way. That’s not their concern. They just want to get the job done. 

Workload Assumptions: The same pricing and budgeting assumption caution applies to workloads. Look carefully at your current utilization and consider how much resources those same workloads would consume in the new environment. There’s a lot to consider. For example, reading a record from a properly designed relational database takes a single lookup. Reading a record from a flat file in a data lake could require sequentially reading many large files. I recall a study completed about a decade ago that found that the total cost to answer certain questions in (low-cost) Hadoop was comparable to the cost to answer that same question in a (high-cost) relational database. You may discover that accommodating the workloads in your current environment will require significantly greater resources in your new environment, whether it’s because you have to construct the solution differently, or run multiple queries or applications, or access more data. Other questions you should ask include: Can the workloads be optimized? Can the environment be designed to reduce resource requirements? And can users be educated to be more efficient (and is that a realistic expectation)?

Pay very close attention to the utilization and workload assumptions. One miscalculation can negate all of your invoice cost savings.

This is especially true with a cloud migration where stories of extreme unexpected cost overruns are so common as to have become cliché.

Δ Cost (Capability)

Following any migration, it is natural for everyone, from every perspective, to expect the replacement to be an improvement. Simplified administration. Advanced security. Higher availability. Greater scalability. Lower costs. Better agility. New capabilities. Nobody expects to have less. Yet when cost is the primary consideration, more often than not functionality is sacrificed. 

Capability Availability: Ask whether it will it be easier or harder for the users and the system team to accomplish what they do today? What new capabilities are being introduced? What existing capabilities will no longer be available? The first step is to take an inventory of the capabilities being used right now, and the new ones that are expected to be required in the near future. Hopefully the current activities will be easier to accomplish in the new environment, but that probably won’t be true for all of them. Some will be harder. Some may no longer be possible at all. The business value of the current capabilities can be used as a baseline, so all we have to look at are the differences. Quantify the business benefit gained with the availability of new capabilities, and the business benefit forfeited with the loss of existing capabilities. (Keep in mind that these differences may also impact the utilization and workload assumptions and estimates.)

It’s also useful to dig a little bit. You may discover that the migration may benefit other areas of the company where the connection is less obvious, perhaps through standardization or interoperability. Be sure to capture and quantify those as well.

Learning Curve: Unless you’re migrating to a platform that everybody already knows (for example, a lift-and-shift from the on-premises to cloud version of the same product), expect a learning curve. Some are steeper than others. During that time, nobody will be functioning as efficiently as they were when they were using the current tool. I’ll talk more about the lost opportunity cost associated with extended project delivery times shortly, but the increased time to complete projects while the team is coming up to speed must itself be considered. If you bring in trainers and consultants to help, be sure to include those costs. And experience suggests that the hand-off is never as smooth and seamless as it is portrayed in the PowerPoint presentations.

Δ Cost (Movement)

This is really just straightforward project planning. The challenge here is understanding the factors that contribute to the migration time, effort, and expense. In general, and not surprisingly, the magnitude of a migration effort is proportional to the magnitude of the difference between the current and future environments. 

At one end of the spectrum is migrating an on-premises or client-based tool into its cloud equivalent. This is likely to be minimally impactful. Maybe some data staging and a few technical or operational issues to resolve. The timeframes are usually short and the whole process is largely transparent to the users.

At the other end of the spectrum is a wholesale tool/platform/database/environment change. Data may have to be organized differently for performance. Different data may be stored in different repositories. Product workflows may change. User tools will have to be relearned. Knowing one tool/platform/database/environment is certainly very helpful, but while the functionality may be analogous the implementation details will differ.

If you are making a significant change to the environment, be sure to consider the time required to re-develop all of the existing analytical artifacts. This can become an extremely expensive activity. Let’s say that ten thousand reports have to be migrated, and that the migration of a single report will take an average of one day to complete. (This is a grossly overly optimistic estimate, since some of the more complex reports and applications can take weeks to migrate and validate, but let’s go with it as a super-conservative average.) That’s ten-thousand person-days, or 40 person years, and at $100k per year, that’s at minimum of $4m just for report migration. 

If you want to finish in a year, you’re going to have to find forty people to migrate those reports non-stop, you’re going to spend four million dollars, and that investment is not generating any new business value. 

Some consultancies have migration tools that automate the conversion, but someone still needs to validate the translation and fix any problems that arise. 

Too often, companies view labor as free. After all, employees will be paid regardless of what they’re doing. But most managers, heck most everyone, would rather that employee time and effort be directed toward changing the business or running the business. Completing a migration expends a lot of effort just to get you back to where you started.

Δ Cost (Business Benefit)

Every published study that I’m aware of concludes that the business benefit either directly generated or indirectly enabled by an analytical environment far exceeds the cost of that environment. When calculating migration cost, it’s critical to quantify the impact to ongoing business benefit. Admittedly this is difficult. Furthermore, finance departments too often ignore this factor when calculating the cost of a project. 

Opportunity cost (or benefit) is a function of delivery velocity; of whether new business value will be delivered faster or slower. Over time, opportunity cost compounds either in a good way or a bad way.

Let’s say that the average analytics project takes six months to complete. At the end of a year, you’ve realized six months of benefit from one project, with a second about to launch. Now, cut the delivery time in half. Not only does the first project end sooner, the second project can begin (and end) sooner. Business value is both accelerated and compounded. By the end of the first year, three projects have been completed and a fourth is ready to launch. And, you’ve got nine months of benefit from the first project, six months from the second, and three months from the third. That’s 18 months total. The time decreased by a factor of two while the benefit increased by a factor of three.

Now look at it from the opposite direction where projects take twice as long to complete. You’ve lost two-thirds of the business benefit. Multiply that by the number of simultaneously impacted project streams. That’s a lot of lost business benefit. Probably a whole lot more than any invoice cost savings. 

If the migration does not result in value delivery acceleration, even if the invoice cost is lower, it will lose money in the long run (and probably the short run). If the only reason you’re pursuing a migration project is to write smaller checks to your vendors, you’re likely to discover that your overall cost will increase.

You’ll spend $10 million to save $2 million. Curiously, this is often considered acceptable. After all, the $2 million invoice cost savings is very visible and comes out of the budget while the $10 million is invisible, absorbed into other line items (and most don’t even consider lost opportunity cost). 

But you’ll know. And your users will know. 

Sometimes the best you can do is to provide the information required to make more informed decisions, and to ensure that the decision-makers consider all of the migration cost factors.