You're gonna get some lock-in

One phrase strikes fear into the hearts of IT, marketing, and senior leadership staff alike. A lone concept that dredges up past pain in a way not many others can. It’s something so distasteful that institutions have changed how they write RFPs. That phrase…

-Vendor Lock-in-

🎵 Dum-dum DUMMMMMMMMM

And to be fair, maybe the idea of being tied to one vendor’s or platform’s requirements should put a little bit of pressure on the procurement process. The problem is — just like hop-ons when driving a stair car — you’re gonna get lock-in.

I say this because, inherent to how modern technology works, you’re always going to be tied to the tech you choose to implement. Even the promise of open source software isn’t free from lock-in. Decided to go with WordPress? Well, when you decide you want to use Drupal instead, you’re going to sink dozens of hours into migrating that site… and they run on the same tech stack.

This gets worse when an organization wants something customized. We came across an RFP that stipulated that the custom web application they want to be built should be movable to different hosting platforms while also maintaining strict security and speed requirements.

The problem is that those things are ongoing maintenance challenges, not one-off builds. The hosting infrastructure, codebase, and engineers who work on apps like that all contribute to how secure and performant a website is.

Higher Ed is Locked In #

So, let’s look back at higher ed. If your institution runs its website on a proprietary CMS like t4, Omni CMS, or Cascade CMS (the big players in our industry), then you chose to be locked in. You see this every day when sending support tickets to your vendor of choice. You see, but may not realize, the consequences of that lock-in.

Maybe you hired developers (or half-developers) who are responsible for working on that CMS in order to offset the support costs or waiting times. Maybe the UX of your CMS hasn’t been redesigned in 15 years. Maybe you still have to template in a language from 1999 rather than using modern approaches. Maybe you still have to maintain a Java server… :shudder:

Even with an open source CMS like WordPress or Drupal, you’ve had to hire PHP and front-end devs (contract or otherwise). You’ve invested in plugins, built custom components, and modified the admin.

Heck, even just being on the internet is lock-in. Look how hard it’s been for institutions to leave Twitter even after it was purchased by a billionaire espousing hate and anti-education rhetoric. And where would we go to advertise other than Google or Meta?

Lock-in actually is all around us #

When an institution chooses to build a website on, say, WordPress, they often think, “Well, we can just switch to a different WordPress shop if we don’t like our vendor now.” And that sounds ideal. But it’s just an illusion of choice. Every dev shop seems to do things a little bit differently, and the budget ones, especially, tend to do non-standard modifications.

So, sure, you could choose to move to another vendor, but time and cost are involved for your new partner to get up to speed. And I’m writing this from experience. We’ve inherited a lot of bad, bloated, poorly written code for WordPress and other CMSs.

The fear here shouldn’t be about vendor lock-in. That’s just the nature of our modern technological world. Really, institutions should be looking at the resources and talent they have in-house, then making sure they’re working with outside agencies who care about your mission and investing their resources into making the tech work for you rather than you working for the tech.

And to me, that’s the most difficult part of any technology decision today. A lot of the bigger platforms suffer from so much technical debt they’ve all but been forced into patching what they have rather than refactoring. There are partners that move their roadmaps quickly and others that require you to get your own dev to carry tech debt along with you. What you want is a partner who is willing to work with you on meaningful changes to their core product at a pace that meets your business needs.

If you’re choosing open source, staff your institution appropriately so that you can do as much as possible with those tools. Alternatively, consider partnering with a web agency of record that can handle all of the maintenance, optimization, and ongoing custom coding for your website or web app. In most cases, that will be much more cost-effective than building out a full dev team.

The reality of all of this is that there are always trade-offs. If you choose that perceived freedom to move from tech to tech or vendor to vendor, you still give up quality and impactful relationships, a voice at the development roadmap table, and a site that keeps pace, if not surpasses, its peers.

My recommendation is to think about the results first. The better your results, the easier it is to justify lock-in as sound strategy.