Somewhere in most established companies there is an application that runs something important and looks like it was built in 2009, because it was. Everyone agrees it needs updating. Nobody starts, because the only proposal on the table is a full rewrite costing a year and risking the operation. There is a middle route, and it delivers most of the value in a fraction of the time.
Rewrites are the default proposal and usually the wrong one
The instinct with legacy software is to replace it. The problem is that an old system that has been in daily use for a decade contains a decade of accumulated correctness: edge cases, regulatory quirks, workarounds for a supplier’s odd data, and rules nobody remembers writing but everybody depends on.
A rewrite has to rediscover all of it, usually by breaking things in production. Meanwhile the business gets nothing until the very end, which is precisely why so many of these projects are cancelled at seventy percent complete.
Modernising the interface is a different proposition. The logic that works keeps working, the risk stays contained, and users feel the improvement in weeks rather than never.
Start where the pain is measured in hours
Do not start with the login screen or the home dashboard just because they come first. Start with whatever costs the most time.
Find it by watching. Sit with the people who use the system all day and note where they slow down: the screen they visit thirty times a shift, the form where they always tab past six fields, the report they export to a spreadsheet because the interface cannot answer the question, the place where everybody keeps a note of the codes to type. Those workarounds are a specification written in the users’ own hand, and watching in silence beats interviewing.
Fixing one such screen properly gives you a measurable result (minutes saved per task, errors reduced) which is the argument that funds the rest of the work.
Constraints you cannot change are constraints, not excuses
Legacy modernisation happens inside real limits, and pretending otherwise wastes everyone’s time. The backend may not be able to give you new data shapes. The framework may not support modern components without a rebuild. Some screens may be generated by something nobody wants to touch. Certain workflows may be legally fixed.
Establish those boundaries in week one, with the developers who maintain the system, then design within them. A great deal is achievable without touching the backend at all: typography, spacing, colour, contrast, hierarchy, table density, form layout, button clarity, error messages, and empty states. Those are exactly the things that make an old application feel unusable, and none of them require new endpoints.
Standardise before you beautify
Legacy interfaces are rarely one design. They are five, layered by different teams over years, so the same action looks different on three screens.
The highest value early work is usually consolidation: one set of type sizes, one spacing scale, one button hierarchy, one table style, one way of showing errors. Building that as a small design system means every screen you touch afterwards is faster to fix, and the product starts feeling coherent long before it is finished.
Fix accessibility while you are here, since old enterprise software is frequently unusable by keyboard and fails contrast throughout, and in many sectors that is a compliance matter rather than a preference.
Density is not the enemy
A common failure is applying consumer aesthetics to professional tools. Airy layouts with generous whitespace look great in a portfolio and infuriate someone who needs to compare forty rows without scrolling.
Professional users want density, keyboard operability, and information on screen. Modernising means making dense interfaces legible through hierarchy, alignment, and restraint, not spreading them out. Keep every shortcut that exists, keep the tab order sane, and remember that a table is often the correct visualisation.
Speed carries the same weight. A prettier version that responds more slowly will be judged worse by people doing the same task all day, which makes responsiveness a feature rather than a polish item.
Ship in slices, and let people adapt
Release screen by screen or module by module, so value arrives continuously and risk stays small. Where a screen changes significantly, run old and new in parallel for a period and let users switch, because fluency is the thing you are disturbing and forcing the change overnight turns an improvement into an incident.
Train nobody on the things that did not move. Announce the things that did. Measure task time and error rates before and after so the next phase has evidence rather than enthusiasm behind it.
Done this way, a legacy modernisation stops being a year long gamble and becomes a series of small, defensible wins, which is also the only version of it that tends to get funded.
Sitting on an internal tool everyone complains about and nobody dares touch? That is a good first conversation: hello@beconfidency.agency.
If you want the modernisation designed and shipped in slices by one team, that is exactly what our product design service is for.