Overcome the prohibitive cost of switching: Part 1, Break the Deadlock

“Yes, we love your solution and everyone in the office hates using our legacy system. But our accounting team still uses it for payroll and they won’t switch.”

I can’t tell you how many variations of this conversation I’ve had with clients both on the service and product sides of my business. 

I feel for them because they are hostages of decisions that were, in most cases, made before they were even hired. Nobody in the mid 2000s thought far ahead enough to plan an exit strategy for their data from the systems they were buying at the time. They were just happy to find a solution that worked for them. 

Maybe this is your situation. As a result, you are sitting on 20 years’ worth of legacy data that is often (like with payroll) subject to regulations. One step in the wrong direction and you are liable–not to mention the cost to pull the data out, reformat it, and import into a new system. 

Any experienced integration engineer will tell you that it’s impossible to predict the kinds of problems you will encounter in this process. 

The only thing you know is that the cost of such an operation will exceed what you initially planned for it. This is when you hear the phrase “prohibitive cost of switching.” You don’t know what the cost might be, but you are sure you can’t afford it.

Is it possible to break the deadlock? In this miniseries of two posts we will look at how you, as a product leader, might break the ice on this idea and overcome the objections against moving your organization to a newer, more productive software stack.

In this first part, we will discuss how to prepare and plan for the transition. In the second, we’ll look at the approaches you need to consider when it’s time to implement the plan. 

Take these posts as a guide that you can apply wholly or partially using your wisdom and institutional knowledge. Such a daring project will certainly require your entrepreneurial brain and tactical abilities, so think of yourself as a general sending a muti-disciplinary army into battle and coordinating individual efforts into a general push towards victory. I have faith in you, soldier!

First, let’s arm ourselves with courage and patience to calculate if the cost of switching really is prohibitive. Then we can build a business case for the switch.

Take control of your data

It’s tempting to start the planning by reviewing the functionalities of various legacy software packages, but this is a mistake. 

Why? Because data is king and information is the blood of your business. All functionality exists to fetch, store, and transform data in one way or another. In a way, that’s all software is: a data manipulation machine.

One of the biggest reasons the cost of switching is so high is historical data. The older the data, the higher the cost is to switch. It’s not only that it’s stored in the format of your original software, but over time it has accumulated inside conventions, caveats, and workarounds that will not translate into a new system.

Before you can get an idea of what an upgrade or replacement project might cost, you need to map where various parts of your core data are hosted and their format. Each software will have its own database and its own way of storing your data, but a map will place all of the vital parts of your dataverse for you. 

The mapping process can be done by looking at the databases themselves (in cases of hosted software), requesting data dumps from the software providers, and talking to specialists in each of your departments that use the software.

Once you have the map, chart the flow of data from one system to another. You will be surprised by what you discover looking at the data flow charts. The charts will give you a clear pathway ahead on how to replace the software package without disrupting the whole delicate operation.

But why do you need to determine a way to access this data? Because, like the mapping exercise, this gives you power and mobility. Because each piece of software then becomes potentially replaceable by exporting data from one package into another.

Finally, this exercise will make your transition cheaper, because you will know exactly where to make the cut, how to export the data, and how to massage and structure it to be imported into the new infrastructure.

Plan in Incremental Steps

In a monumental undertaking like this, you can’t switch in one fell swoop. It would be too risky. 

Your switch has to happen gradually. To quote the great philosopher Jerry Seinfeld, “It’s like knocking over a Coke machine. You gotta rock it back and forth.”

Incremental steps means that you will have to deploy temporary solutions, which may seem to some like a worse off situation than pre-transition, but these steps will take your organization to a much better outcome.

What’s the best way to go about making a transition plan? If you are replacing one software package with another in a chain of connected software, then it would be a matter of replacing identical interfaces and data formats so the entire chain works again. 

For example, if you need to replace payroll software in the data chain of CRM -> Crew Management -> Payroll -> Invoicing, configure the new system to receive whatever Crew Management is putting out and Invoicing is accepting as input. The other major thing would be to make sure there’s feature parity between the old and new payroll software.

And in the more difficult case of replacing part of the functionality of an ancient (about mid 2000s in our case) monolithic system, incremental steps really come in handy. 

As an example, let us imagine a reverse situation, when you would like to replace an old monolith, but the accountants are refusing because they don’t want to replace the payroll module. In my experience, this situation is much more common. 

In this case, put on your negotiator hat and sit down with the team to understand what part of that software really holds them in place. It’s never the entire module–usually it’s a certain bit of functionality they cannot replace with anything else. Let’s call it the smallest irreplaceable denominator. Once you’ve identified what that is, you can transfer the functionality around it to the newer stack. For instance, if the irreplaceable denominator is an antiquated bank connection that sends in payment data in a certain format, leave that in place, but peel off staff records and transaction calculations.

A strong relationship with the solution provider is important, as they will help you configure or customize their software in order to accommodate your plan. Solution providers are interested in a successful integration effort and are happy to provide engineers for this purpose. In fact, for many of them, a large part of their revenue comes from these professional services.

Compromise is the key here. Switching will happen incrementally, so be prepared to make peace with intermediary steps before the process is complete.

Just How Prohibitive is the Cost?

Now, we come to the payoff. Having mapped your data flows and made plans for incremental transition, it’s time to calculate the cost. The process of estimation is not a straightforward topic and deserves its own post, but let’s touch on the approach to estimating. 

Do you hire an outside agency to give you an estimate or use your internal resources? 

Here’s my personal observation on the issue: Unless you are a tech-first company, internal IT resources are motivated by and are evaluated on the performance of current infrastructure. In other words, they are risk-averse. 

Transition projects are a risky endeavor, they create a conflict of interest for your IT team, so it’s natural for them to try and de-risk this project by padding their cost estimate as much as they can. The estimate they present may be a lot more prohibitive than it needs to be.

On the other hand, an agency’s incentives are better aligned with yours. They are motivated to present realistic figures. On the one hand, they need to take all costs into account to make money on the deal, but on the other hand, they can’t overinflate the estimate because they risk losing the contract entirely. 

Build the Business Case

With a reasonable cost estimate in hand, you get to prove the case for switching to your superiors, but in a different way than to your team. For employees, the argument is simple: the new toolset will make you more efficient and your work more enjoyable.

The case to management is always made in terms of return on investment. You have to answer the question: How much can the company save in the next five years by switching to the proposed software stack? 

Some costs are not obvious and have to be approximated. But it’s still important to account for them to build a proper case for switching. You might consider lost efficiency hours or even how you have to pay interns to perform tasks that compensate for deficiencies in data structures.

If you can show that today’s pain and expense of switching will yield bigger savings or revenue a few years down the road, it will help unlock the path to upgrade.

Another aspect of this case is risk management. The fear of loss is a stronger motivator than the promise of gain. You need to anticipate the objections your peers or superiors will raise and prepare mitigation tactics for each of them. Make them feel like they have nothing to lose and everything to gain by choosing to upgrade the solution.

Moving On to Implementation

These steps will help you move the needle from zero. Your company’s leadership will understand that a switch needs to happen from a business perspective and that you have a plan in place to make it happen technically. 

That’s already an impressive achievement on your part, my fellow tech leader. In the second post, we will move into the implementation of the plan, which is fraught with its own pitfalls. But let’s cross that bridge when we come to it.