Thousands of users have trusted your software for years. You have a loyal customer base, a dedicated design and development team, and a sterling reputation. So, why fix what isn’t broken?

There are several reasons to consider transforming your legacy software, including:

  • Lagging behind competitor products that are easier to use, more cost effective, or that incorporate new features
  • Being unable to meet requests from your most loyal users for features that are ubiquitous in newer products 
  • Struggling with an outdated user experience that is frustrating users or that only a cadre of “power users” understand 

If these sound familiar to you, it may be time to contemplate updating your software to match the expectations of today’s user base. 

But making this change isn’t easy. Here are two insights to consider when you’re ready to make a big change to your legacy software package.

Welcome fresh perspectives—but be ready for heavy lifting.

One of the most effective ways to start evolving your software is to welcome new perspectives to the conversation. In its simplest form, this can include a review of your software by internal employees who aren’t members of your product team. If you’re looking for more technical recommendations, however, you may want to turn to an outside consultant, an external design team, or another UX professional with no previous experience using the software. 

Finding an independent outside perspective helps us avoid confirmation bias, a common pitfall of design teams that have worked on the same product for years. This can also allow your product team to see the software through new eyes, often resulting in unexpected insights and ways of working. 

But putting together a new consulting team doesn’t instantly result in product improvements. The recommendations they make still need to be put into practice, and this is where the heavy lifting starts. If you’re considering major changes to your software, think about the best use of your existing resources. 

Your current product team needs to focus on keeping the legacy software running, so how many of your designers and developers can you spare to build something new? Conversely, if you bring in an outside team to build a new version of the product from scratch, how can you ensure you capture institutional knowledge and best practices? 

There is no one-size-fits-all approach to revamping a legacy product, but these are critical questions to ask within your organizational context before launching your own effort. 

Involve your users in the conversation. 

Before you “rip and replace” your legacy software with something brand new, there’s one group of people who must be part of the conversation: your users. Chances are you probably already conduct some user research, whether that’s feedback surveys or polls, check-in calls with your most loyal clients, or special “feature releases” for select groups. 

If you’re aiming to significantly change the way your software looks and works, though, you’re going to need to speak even more widely to your user base. There are a variety of different ways to involve your users in the conversation, including:

  • Selecting users to participate in UX interviews from your sales and marketing databases
  • Offering incentives for users to conduct UX interviews with your team
  • Recruiting users with financial rewards to demo new features
  • Using social media to capture fans of your software for interviews 

User Interviews has an extensive guide to recruiting participants for UX interviews, including a special section on finding interviewees who already use your product.

Updating your legacy software is a watershed moment for your product. Make sure you take full advantage of the moment through strategic thinking, in-depth research, and robust user testing.