Part 1 of the Hidden Costs of Migration introduced the key high-level challenge associated with hardware and software migration projects:
They’re not change the business. They’re not run the business. They’re a full stop, with the expectation that progress will be faster when it’s finished.
The objective, then, is to offset the ground lost during the migration with the ground gained afterward.
In Part 2 we examine the specific cost factors that can be used to objectively evaluate the advisability of the migration project—supporting moving the project forward or reconsidering it—and to provide insight into focus areas and activities that can improve the probability of success.
Four different types of costs, or cost pools to borrow from Activity Based Costing, collectively contribute to the overall cost of the migration: invoice, capabilities, movement, and business benefit. The number on the invoice is just one factor, and 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 (Capabilities) + Δ 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 whatever it is. Then, after the trial period, the price increases. 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 at all on that, 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 assumptions apply to workloads. Look carefully at your current utilization and consider how much resources those same workloads would consue 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 a question 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 to ask are whether the workload can be optimized? Can the environment be designed to reduce resource requirements? And can users be educated to be more efficient?
Pay very close attention to the utilization and workload assumptions. One miscalculation can negate all of your invoice cost savings.
Especially in a cloud migration. In the data center world, we bought hardware and software. When we reached maximum capacity, we either bought more or we made do with what we had. But the cloud is, in theory, easily and infinitely expandable. Need more capacity? You got it with the press of a button. But you pay for everything. Every CPU cycle. Every byte written, stored, and retrieved. Every packet across the network. Stories of extreme unexpected cost overruns are so common as to have become cliché.
Δ Cost (Capabilities)
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 and greater scalability. Lower costs. Better agility. New capabilities. Nobody expects to have less. Yet when cost is the primary consideration, more often than not it is functionality that 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, 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 existing 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 cost. 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 probably a grossly overly optimistic estimate, since some of the more complex reports and applications can take weeks to migrate and validate.) That’s ten-thousand person-days, or forty 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. And remember, 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 being 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. And then they have the nerve to wonder why business value is not being generated as quickly as they had expected.
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 time to delivery 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 eighteen 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 now take twice as long to complete. You’ve lost two-thirds of the business benefit. Now multiply that by the number of simultaneously impacted project streams. That’s a whole lot of lost business benefit. And almost certainly a whole lot more than any invoice cost savings.
When the migration project is completed, business value must be accelerated in order for the company to recoup its investment in the cost of the migration. 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 we don’t even consider lost opportunity cost).
But you’ll know. And your users will know.
So, at least make more informed migration decisions by considering ALL of the cost factors.
Cover image, “Checkbook” by jridgewayphotography at flickr.com. Copyright 2011, some rights reserved.
0 Comments