Product Modernisation
Product modernisation is updating an established software product's workflows, interface and underlying code while keeping the behaviour and data that customers still rely on. It matters when a product is too valuable to abandon and too costly to keep patching.
- Product strategy
- Modernisation
Product modernisation examples from two established products
Somebody has already said “just rebuild it” out loud. What must survive is as much the question as what must change.
Application modernisation can mean moving the software to new hosting, rebuilding its structure underneath, replacing parts or retiring them. Product modernisation works out how each of those changes affects the people using it.
It reaches further than a visual redesign and stays closer to the product than a platform migration. A team might keep bookmarked links and saved work while replacing a broken status system, one complete working path at a time. Each capability can be kept, repaired, redesigned, moved to a new platform, rebuilt or retired.
UX debt explains why repeated workarounds make further change costly. A Product Modernisation Assessment helps choose the right intervention.
Explore Product Modernisation or the Gold Image Printing web-to-print modernisation.
Product modernisation starts with the one capability under pressure. It works out what behaviour must survive, what can change and which dependency actually limits the product.
Benchmark Gensuite used shared-component and coded-prototype work to review a modernisation direction before wider implementation. Tcules started with the shared components, then tested them inside the scope selector, where people choose which part of their organisation they are working in.
At Gold Image Printing, an online print store and an internal ERP had to change together. Tcules observed production staff at work, redesigned the customer and production workflows, and created shared components and a style guide for both sides.
The Product Modernisation service can combine research, redesign, Design Systems, Design Engineering and software delivery, according to what holds the product back.
Product modernisation vs legacy modernisation, redesign and replatforming
The four terms overlap, and projects often combine them. The main question each one asks is the quickest way to tell them apart.
| Intervention | Main question | What may stay unchanged |
|---|---|---|
Product modernisation | What should change, what should stay and how should the transition happen? | Any capability or foundation that still serves the product |
Legacy software modernisation | How do we move off ageing technology without breaking the work the business runs on? | Workflows, data and integrations people still depend on |
Product redesign | How should an established workflow or interface change for existing and new users? | Sound technical foundations and unaffected product areas |
Replatforming (moving a product onto a new technical platform) | How should product behaviour map to a new platform, and how do users get there? | Behaviour that the new platform can support without harmful change |
Questions about product modernisation
How is product modernisation different from legacy modernisation?
Legacy modernisation usually starts from the technology: ageing code, hosting or integrations that have become a risk. Product modernisation starts from the product and the people using it, then works out which technical changes they need and in what order. The two often run together on the same system.
Is product modernisation the same as a redesign?
Redesign is one of several tools that product modernisation can use. A modernisation project might also rebuild parts of the code, move to a new platform or retire features. It plans how customers get from the old version to the new one. Some products need a redesign alone.
What are the signs a product needs modernisation?
Common signs are changes that take longer every release, workarounds new staff must be trained on, and an interface prospects call dated. Another is a team that avoids certain areas for fear of breaking them. A Product Modernisation Assessment sorts which signs call for modernisation and which for a smaller fix.
How Tcules modernises established products, and related terms
We work toward an established product that can take on new features without breaking the work customers already do. Separating what still works from what has become a constraint is the first modernisation choice. When an established product is modernised to take on AI features, the same first choice applies: decide what must keep working while the product learns to do something new.
Shared components and a style guide often become the foundation for that change, as they did at Gold Image Printing. A design system takes the same idea further. Information architecture matters when the product's records and routes have to be reorganised along the way.
Tcules runs the full job through Product Modernisation. Product Redesign and Legacy Software Modernisation cover narrower jobs.
Discuss your product modernisation
Talk to Tcules about the product, workflow, interface and implementation changes your established product may need.