Software migration: Pain vs Risk

“And the day came when the risk to remain tight in a bud was more painful than the risk it took to blossom.” – Anais Nin

Over the course of my career, I’ve experienced my fair share of software upgrades, migrations, and replacements. Some have gone smoothly. Many have not. But none of them could be described as “easy”. The reason none were is is because, to paraphrase a famous sword-swinging Spaniard, “…that word doesn’t mean what you (non-IT people) think it means.”

In tech, and especially on the subject of system migrations, “easy” connotes “without significant unexpected issues”. It rarely – possibly NEVER – means “without effort.”

Nevertheless, the suggestion to upgrade (or migrate, or replace) is often thrown around by certain folks (usually business leaders and vendor sales) without a trace of understanding of what that truly entails. As a boots-on-the-ground IT practitioner, hearing it used in this way is nothing short of infuriating.

Upgrades are such a monumental task that teams will go to almost any length to avoid them unless absolutely necessary. “Almost any length?” you ask. A recent LinkedIn post* illustrates just how bad it has to be for a customer to consider migrating:

* I recognize readers might read this particular post and read into it a certain venting of grievances on my part, as a former SolarWinds employee. I want to be clear (and I spell it out below) that this is not the case because MANY vendors are making changes to pricing, causing MANY customer to feel similarly to the original poster. This post is just the most recent one to have crossed my timeline.

SolarWinds, a major player in the technology infrastructure monitoring space, is attempting to force our company into a three-year deal that represents a 543% price increase from our 2023 costs. To put this in perspective. they’re charging 5.6 times the inflation rate. […] I’m now being asked to pay more to monitor our company’s infrastructure than I pay to support that infrastructure itself.

If there is a lesson in this that avoids both showcasing the pain of others (in this case, Mr. DeMersseman) or pointing fingers at any specific vendor (because SolarWinds isn’t the only culprit here by a long shot), it’s that customers – despite the lack of meaningful updates or new capabilities; despite the jacked-up pricing and removal of flexibility; despite almost open hostility from the vendor C-suites – despite all of that and more,  STILL haven’t migrated to another tool.

Why? Why would they do that? Because migrating is HARD. In this blog I want to outline just how much risk there is in “blossoming” (as a reference to the quote at the top of this post, by which I mean “migrating to something new”). So much that customers are willing to tolerate this level of pain to remain “tightly within the bud” of the current monitoring solution. I want to outline exactly what you* are asking of your team, when you are being courted by a new software vendor who is promising they can do everything the incumbent solution does (and more, and better) if only you’d switch to their solution. Making matters worse, you* are probably laboring under the belief that “we have too many tools already” (which is, to be honest, probably not entirely wrong.) and so you’ll only consider “…putting a brick in if we can also take a brick (or 2, or 3) out.”

* I’m assuming that YOU, dear reader, are part of the decision makers who buy the software. If you’re not, then I’m writing this to be shared with said decision makers. You’re welcome.

Let’s break down exactly what a software migration looks like – at least in my experience and in my not-so-humble opinion.

First, let’s be clear: I’m talking about the experience of an boots-on-the-ground IT practitioner who has found a tool that does something both important and essential. So much so that they’re willing to attempt the “business justification two-step”.

Imagine being that regular IT pro walking into a room of executives asking questions like the ones Keith Townsend (CTO Advisor) describes in this LinkedIn post. It’s not fun.

Tech people hate (and therefore usually suck at) speaking in terms of the business, so these types of meetings usually devolve into the IT person passionately citing technical stats until the executive shuts them down or caves. For the sake of argument, let’s pretend they cave (spoiler: they never do).

I’ll also remind readers that “I’m adopting a new tool” isn’t seen by most managers as a hall pass to get out of doing your regular job (which is typically 3-jobs-in-a-trench-coat that consumes 50+ hours a week).

The ADDITIONAL work on top of the normal work includes:

• Creating the forms for a largely un-necessary RFP.
• Working with companies who don’t have a free tier to get a free trial going without making it sound like buying is a sure thing.
• Apologizing to the CFO when an over-enthusiastic salesperson skips 2 or 3 levels and calls them directly to see if they can “push” the sale through.
  • Yes, that happens. 2 different monitoring solution vendors have done it to me.
• Begging for cash and scrounging spare parts to build a lab because nobody will (justifiably) let you test in production.
• Setting up the lab yourself. Even the people who would benefit from the new tool usually can’t help because – SURPRISE – they are doing 3-jobs-in-a-trenchcoat too.
• Doing the RFP – installing and configuring software for at least 3 companies plus the incumbent and doing detailed comparisons in an attempt to get an apples-to-apples understanding.

But, ok, that’s ANY migration. So let’s wave our magic wand again say we get past the WEEKS (if not months) of effort. AND we’ll wave our wands yet again to ignore the weeks of back and forth with purchasing, who won’t understand what the tool does and nor they think the company needs it because it’s “just another piece of software.”

Congratulations! You’re magically past those ulcer-inducing stages. NOW you – the beleaguered IT person – are on the hook to:

• Inventory all the systems that will be part of the pilot program.
• Set up a QA environment for the new software, against the QA environment of the new application.
• Explain to the vendor that you actually need TWO copies of the software, not one, and no you don’t have budget to pay for it twice, you need a free copy because it’s just QA.

Once again, we’ll pretend the vendor just say “duhhhh okay!” (spoiler: they rarely say that). Next on the list is to:

• Install and configure the new vendor’s software.
• Add the QA environment systems into the environment.
• Manage and monitor the test, showing results to the application owners to prove your new software won’t destroy their app.

Once you’ve passed those items, the work is not done. You now have to:

• Set up the new vendor’s software in the production system.
• Add (not migrate) the application(s) to the new system.
• Run the new system in parallel with the old one for a number of weeks, reporting comparative results to everyone up to the CFO’s father’s, brother’s, nephew’s, cousin’s, former roommate about how it’s going.
• After that period, you can start to turn off (not delete, just turn off) the old vendor’s software. Note that your company is still PAYING for the old software, so exactly ZERO savings have been achieved. Try explaining THAT to the CFO.
• During all of this, you are also responsible for re-creating all of the tests, alerts, reports, and dashboards in the old system that people now “desperately need” (even though they haven’t touched them in 2 years.)

Scroll back and review all those bullets one more time. Ask yourself what it would take to make you want to do that on top of your existing work. Most IT folks go through that kind of experience ONCE, often because they don’t realize what they’re in for. After that, most learn their lesson and stop asking about (or for) new tools because very little would be worth all (or any) of that.

“But Leon, companies DO aquire new tools. All the time. How do you explain THAT?”

Final spoiler: We wait for something to explode. We wait for a system we know is unstable to experience a surface-of-the-sun hot nuclear melt down. Because at that point, all the hurdles and bullshit clear away. The executives who were so picky before are now screaming bloody murder. They’ll do ANYTHING, agree to ANYTHING, to make sure that EXACT PRECISE problem never happens again,

Then and only then can a tool be adopted quickly.

This is why we can’t have nice things. Or at least, this is why IT folks don’t jump up and down with joy when you suggest they migrate to a new monitoring tool, despite their frustration with the current one.

So don’t be surprised when they don’t.