We’ve seen the term “app modernisation” showing up more frequently on a lot of software and developer websites – one sure sign of a trend on the rise. A definite subset of digital transformation, there’s substance behind the term: research has uncovered large numbers of organisations whose applications need refreshing. So now’s a good time to start thinking about app modernisation through the lens of three key questions: what is it, why do it, and how to go about it. In a way, the first two questions are linked. Once we start to define what app modernisation is, the why soon becomes clear. It deals with the applications we tend to think of as the front end of your business processes. They’re legacy tech: they’ve been there a while and, to put it politely, they’re probably starting to show their age. It’s a common problem. Legacy apps remain widespread. A survey of 1,000 IT decision makers by Red Hat in 2024 found that 75% said their organisations had already completed at least small-scale modernisation projects, with 24% still in the learning phase and most somewhere in the middle of their journeys. Why modernise your apps? There are usually one or more triggers to modernise. Maybe the tech stack has some cybersecurity flaws due to old code; maybe the databases and servers the apps are built on are beginning to creak, to the point of becoming a limiting factor. The business wants to add features or functionality but the architecture doesn’t allow that, which means the business can’t fulfil a customer need, or scale, or move into new markets. Another urgent reason is the changing competitive landscape. To anticipate new entrants to the market, traditional companies – which by definition are more likely to have legacy apps – need to up their game. And now we have AI, which could potentially disrupt things further. (For more reading on what’s happening right now, I recommend Tom Goodwin’s LinkedIn posts which are an excellent source of thinking about differentiation, branding, technology and so much more. Here’s one great example where he talks about the tension between traditional players and new market arrivals.) Over the years, many organisations overcame this hurdle with APIs – a middle layer that allowed the front end to talk to whatever system was behind it. Often, however, this was the start of what would ultimately become experience debt, which Brian talked about in a recent blog. This manifests as poor CX or UX: what customers and end users feel when using your applications. The customer question Which leads us on to another important reason to upgrade: if the customer’s getting a disjointed experience because there’s been a lack of consistency in what you’re rolling out due to mergers or other apps bolted on, they’re probably not able to do what they would like to do with your app. And that leads to dissatisfaction and churn. This is an expensive outcome because you’re either incurring more cost to win new customers from somewhere else, or you’re paying extra to support the ones you still have. Companies have been trying to solve this with chatbots but I would argue that if you design things properly to begin with, you minimise the need for customer support and chatbots in the first place. So for a business that’s burdened with both technical debt and experience debt, app modernisation is a great opportunity to deal with both at the same time. As an added bonus, you might find you can do away with or cut back on processes you thought were essential but aren’t. The situation reminds me of when moving to the cloud started to become viable. To describe the options facing businesses as they evaluated what to do with their apps, in 2010, Gartner coined the five r’s: rehost, revise, rearchitect, rebuild, or replace. A similar spectrum of choices faces organisations now as they think about modernising their apps. An important shift in perspective The five r’s are useful but they don’t tell us the full picture because when deciding to embark on a modernisation journey, you also need to look at the front end experience from your user’s perspective. I can’t urge this point strongly enough: and I don’t just mean the pixels on the screen but the full end-to-end customer journey. This is where we come to a key step in the entire process: extensive user research. There’s a good example of how we did this for Zurich, which developed a dashboard to give its customers self-service features. It had been relying on manual processes like letters and phone calls. App modernisation allowed customers to request policy updates or change personal information through Zurich’s app. In similar projects, for financial services clients and customers in other industries, we’ve been carrying out a lot of user research. Essentially, this involves talking to customers to understand their pain points. You can’t short-cut this stage: you have to walk in your customers’ shoes. You might think you know your customer but you’re not them; so the best thing to do is user testing, involving real people with real applications and real problems. A lot of this process involves qualitative testing and the value is in how it unearths a mine of information about the issues that customers have – and very often, insights into how to fix them. Why design leadership matters for modernisation Now let’s suppose your business has decided strategically that it’s going to modernise its apps. This project is too big to be led by IT alone; it has to be holistic, with design included from the start. With all of our projects, we collaborate alongside development, to work within the constraints of whatever the tech is, while pushing at the boundaries and testing the art of the possible. Many companies have in-house digital design teams but are they stuck in business-as-usual mode: tactical work to keep the lights on? Is there sufficient deep experience in UX and experience design that can articulate a vision for a new or modernised product? You might have strength in your IT team to deliver an app that’s fast, secure, scalable, but do you have the equivalent strength on the design side (we call this design leadership)? When it comes to app modernisation, don’t fall into the trap of making it look ‘modern’ while not addressing fundamental design issues. Front end design evolves and goes through phases; drop shadows and square corners come in and out of fashion. I’m talking about something far more fundamental: how easy it is for a customer to use your app. That is, and always should be, the North Star for your app modernisation project. By the way, it’s also the right thing to do because it draws upon good practice in accessibility. From June 25, the European Accessibility Act comes into law so modernising your apps is a great way to address considerations like contrast, text size, along with interaction design so it’s obvious to the user what the next step should be. All of these changes need addressing at the development stage. They’re harder and more expensive to do after the fact. That’s why it’s vital for design to be involved from the start. The project needs to align with what your company is trying to achieve, and the specific design needs to be informed by user research and testing. For that to happen, design needs to have a voice that carries weight at leadership level.