By Mehdi HassanEnterprise software rarely dies. It accumulates. A product built a decade ago still runs payroll, inventory or claims, and the people using it have learned a hundred small workarounds to get through their day. Redesigning that kind of system is less about pixels than about risk: how do you modernize the interface without stopping the business that depends on it? This guide lays out a step-by-step approach that has worked well for teams in that position.
How do you modernize the UI of legacy enterprise software?
You modernize legacy enterprise software by designing a complete target interface, then replacing the old front end one area at a time while the existing back end keeps working. This is the strangler pattern applied to UI: new screens grow around the old system until the old screens can be switched off.
The alternative, a full rewrite launched on one date, is tempting because it promises a clean slate. In practice, it tends to run long, miss features nobody documented, and force users through one enormous change. The incremental approach is slower to finish but delivers value from the first slice. It's one of the scope options covered in our SaaS product redesign guide, adapted for older and larger systems.
What is the strangler pattern for legacy UI redesign?
The strangler pattern is a migration approach where a new system gradually takes over pieces of an old one, routed through a shared entry point, until nothing of the old system remains in use. Software teams have used it for back-end migrations for years; it works just as well for front ends.
For a UI, the shared entry point is usually a new application shell: the navigation, header and login. Behind it, some routes render the new front end and others still load the legacy screens, sometimes embedded, sometimes linked. Each release moves another area across. Users see one product with a consistent navigation, even while the inside is half old and half new.
Approach | Risk | When users see value | Best for |
|---|---|---|---|
Big-bang rewrite | High: one launch, many unknowns | At the end | Small systems with few users |
Visual reskin only | Low | Quickly | Systems that work but look dated |
Strangler-pattern redesign | Moderate and spread out | After the first slice | Large systems people depend on daily |
Step by step: how does a legacy software redesign run?
A legacy software redesign runs in six stages: discover real usage, design the target, build the shell, migrate a first slice, repeat area by area, then retire the old UI. The design work is front-loaded so every slice follows the same system.
Discover how the system is really used
Watch long-time users work. Record the workarounds: spreadsheets on the side, copied IDs, browser bookmarks to deep screens. These are requirements nobody wrote down, and the new design has to cover them.
Design the target experience for the whole product
Define the new navigation, layout patterns and components across all areas, even those you'll migrate last. Without a target, each slice invents its own patterns and the product fragments again.
Build the shell and shared components
Ship the new navigation and header around the legacy screens first. Build the core components in code: tables, forms, filters, dialogs. This is the foundation every slice reuses.
Migrate a first slice
Pick an area with high traffic and low risk, such as search or a read-only record view. Rebuild it on the new front end, release it behind a flag, and fix what users report.
Repeat area by area
Move the next area across, in an order set by value and risk. Keep data and business logic in the existing back end, connected through APIs, until the front end is stable.
Retire the legacy screens
Once an area has fully moved and its old routes see no traffic, remove them. Announce the end date for the old screens in advance so nobody is caught out.
How do you choose which screens to redesign first?
Choose the first screens by scoring each area on traffic, risk and dependency: high traffic, low risk and few dependencies go first. Traffic means more users benefit early. Low risk means mistakes are recoverable.
- Good first slices: global search, read-only detail views, dashboards and reporting screens. Many people use them, and errors don't corrupt data.
- Middle slices: common create and edit forms, once the form components are solid.
- Late slices: complex multi-step workflows, bulk operations, anything touching money or compliance, and admin settings.
- Leave alone, possibly forever: rarely used screens that work. Linking to them from the new shell is often cheaper than rebuilding them.
How do you redesign without breaking long-time users' workflows?
Protect long-time users by keeping their speed: preserve keyboard paths, dense views and deep links, even when the new interface looks cleaner. Expert users of legacy software are often faster than any new design at first, and they'll resist a modern UI that slows them down.
Offer a compact density setting for tables. Keep or remap keyboard shortcuts. Make sure old bookmarked URLs still land somewhere sensible. And roll out each slice with an opt-in period, a clear announcement and a feedback channel, as described in our guide to rolling out a redesign. When in doubt about how much to change, the comparison of redesign vs refresh vs incremental improvement helps you pitch the scope per area.
For example, suppose a logistics company modernizes its dispatch software
Hypothetical example: a logistics company runs dispatch on a desktop-era web app. Dispatchers know every shortcut and dread change. Discovery shows that they keep a spreadsheet open to track drivers' breaks, because the system has no view for it.
The team designs a full target interface, then ships a new shell and a new shipment search as the first slice, with the same keyboard shortcuts. The second slice is a driver availability view that replaces the side spreadsheet, a visible win for dispatchers. Only after those land does the team move the complex route-planning screen, using components already proven in production.
Who do you need on a legacy software redesign team?
A legacy software redesign needs product design, front-end engineering and someone who understands the existing system's data and business rules, working as one team. Splitting design and build across separate vendors is where these projects stall, because each slice needs design and code decisions made together.
The roles blur in a good team. Our guide to product designer vs UX designer vs UI designer explains who does what, but on legacy work the important part is that the people designing the new screens can see the constraints of the old system and the cost of building around them. That's why we work as one team that owns words, design and code.
How much does modernizing legacy software cost?
The cost of modernizing legacy software depends mostly on the number of areas you migrate and how much of the back end needs new APIs, not on the visual design. Because the strangler approach spreads work over time, it's usually budgeted as ongoing capacity rather than a single fixed project.
A sensible way to start is a fixed-scope design phase for the target experience and the first slice. Our $3,000 sprint delivers a redesign direction and 10 product explorations in Figma, which is enough to align stakeholders on the target before you fund the build. The incremental rebuild then fits a monthly model; our $6,000/month retainer is a design and development team for that kind of rollout. For market ranges and budgeting detail, see app redesign cost.
