Old software doesn't just look bad — it works badly. Every year, businesses keep patching systems that should've been scrapped a decade ago. Designers get handed a Figma brief and a codebase from 2003 and told to "make it feel modern." This piece is about what actually happens when that collision occurs and why a visual overhaul without touching the backend is basically expensive window dressing.

The Market Moves. Legacy Systems Don't.

Most enterprise software looks exactly like what it is: something designed before the first iPhone dropped. SAP ERP interfaces from the early 2000s. Banking portals running on COBOL. Insurance platforms on AS/400 that nobody under 45 knows how to maintain. These things are still live. Still handling real money. Still making every person who touches them miserable.

The design world, meanwhile, has moved fast. Design tokens, accessible component systems, motion design, dark mode — the vocabulary of modern UI has expanded in ways that old tech genuinely cannot support. A decent designer can mock up a slick onboarding flow in two days, while businesses can also create a logo using modern AI-powered tools to establish a polished brand identity in minutes. Getting that flow to function inside a 20-year-old monolith? That's a project measured in quarters, not sprints. 

Real transformation means rethinking not just how the interface looks but how the underlying systems communicate and scale, and that's exactly the scope that application modernization and migration services cover in practice. Most design briefs quietly skip past this part. They shouldn't.

Why the Backend Is a Designer's Real Enemy

The Invisible Architecture Problem

When a designer opens a legacy product, they see an ugly interface. The actual problem is sitting three layers deeper — invisible, but very much in charge.

Legacy systems typically run on monolithic architecture, where the database, business logic, and UI are tangled into one enormous codebase. Server-side rendering only, which means the frontend can't update anything without a full page reload. UI logic is baked into backend templates instead of living in a design system. And either custom proprietary APIs or, honestly, no real APIs at all.

The NHS is a useful reference here. Before their digital push, clinicians were clicking through 15+ screens to pull up a single patient record. The visual problem was obvious to anyone with eyes. But actually fixing it meant restructuring database schemas, remapping data flows, and migrating services to cloud infrastructure. Years of work. Not a redesign sprint.

"Just Update the CSS": The Most Expensive Four Words in Tech

This conversation happens in agencies all the time. A client wants a fresh look. Designers deliver something clean and well-structured. A developer opens the codebase and finds the entire UI rendered through server-generated HTML with inline styles, built on a framework deprecated a decade ago.

You can't drop a component library on top of that. You can't make it responsive without effectively rebuilding it. The design sits in Figma, looks great in presentations, and ships nothing.

What Modernization Actually Means

There's a lot of vague language around this subject. "Digital transformation." "Cloud migration." "API-first." Let's be specific.

• Layer 1 — Presentation. This is where UI/UX lives. Typography, layout, interactions. The most visible layer, the easiest to prototype, and entirely dependent on what's beneath it.
• Layer 2 — Application logic. Business rules, data processing, integrations. In a monolith, this is bundled with everything else. Modernized systems break it into microservices — small, independent modules that communicate through APIs.
• Layer 3 — Data and infrastructure. Databases, hosting, storage. Legacy systems often run on-premises with rigid constraints. Moving to AWS, Azure, or Google Cloud is frequently a prerequisite for any serious UI work.

A designer working on a bank's onboarding flow needs to understand that their screens depend on a microservice for identity verification, another for account creation, and another for KYC. If those services don't exist yet, the design doesn't ship. It waits.

The Strangler Fig Pattern

One of the more sensible approaches to this problem is called the Strangler Fig pattern, named after the vine that gradually replaces a host tree. The principle: don't replace the entire legacy system at once. Build new services alongside it. Route traffic incrementally to the new components. Slowly phase out the old system until nothing remains.

Amazon used this to shift from monolith to microservices over several years. Not a big-bang migration — a long, deliberate handover. For designers, this means the product looks inconsistent for a while. Old screens and new screens coexist. That's intentional, not a failure.

Technologies That Make Modern UI Actually Possible

Getting specific matters here.

• Frontend frameworks — React, Vue, Angular. The foundation of any modern single-page application. Legacy systems on JSP, Struts, or classic ASP can't use these natively; moving to them requires fully decoupling frontend from backend. Next.js and Nuxt.js work well when server-side rendering is still needed but with the flexibility of a modern component model. Spotify and IKEA have both leaned into micro-frontends — a model where separate teams own separate parts of the UI entirely independently.
• Design systems — Storybook for building and documenting components in isolation. Figma with Tokens Studio for managing design tokens that sync across design and code. Zeroheight or Supernova for bridging design documentation into something developers actually open.
• API layer — GraphQL lets frontend teams request exactly the data they need, which matters enormously when the legacy backend returns enormous, poorly structured payloads. Converting old endpoints into managed API gateways (AWS API Gateway, Kong, Apigee) means new frontends can consume existing backend logic without anyone touching the core system directly. Event-driven architecture — Kafka, RabbitMQ — enables the real-time UI behaviour that most legacy systems simply couldn't produce.

Cases Worth Knowing

1. Airbnb's DLS. Airbnb spent years rebuilding its design system. The visual results looked cohesive. What made it work was a dedicated platform engineering team maintaining a shared React library in parallel — designers couldn't ship components without that infrastructure being ready. The partnership between design and engineering was the actual product.
2. Commonwealth Bank of Australia. CommBank's mobile app — clean, genuinely usable by financial services standards — required years of backend modernization running alongside the frontend work. Core banking systems migrated to cloud incrementally. New API layers built to serve the new interface. Design didn't do that alone.
3. The projects that didn't work. A large European retailer redesigns their e-commerce frontend, launches it, watches conversion drop — because the new checkout flow depends on a payment integration the legacy order management system can't reliably complete. The design was fine. The architecture wasn't ready. This isn't a rare edge case. It's a very common outcome when design and engineering modernization aren't synchronized.

What Designers Need to Ask Before Starting

Before any legacy redesign goes into discovery, get answers to these:

• What generates the current UI — server-side templates, a JS framework, something else?
• Are there documented APIs, or does the frontend pull data in undocumented ways?
• Is there a parallel backend modernization planned, or are designers expected to work on top of the existing system?
• Who owns the design system after launch? A redesign without maintenance is a redesign that degrades in 18 months.
• What does "done" look like? A phased rollout plan beats "we'll migrate everything eventually."

These answers come from conversations between design leads, engineering leads, and someone who actually understands the existing system. Not just its surface.

The Collaboration Model That Works

Old model: designers hand off mockups, developers implement them, chaos follows.

What actually works: embedded squads where design and engineering own the same slice of the product at the same time. Agencies like Thoughtworks built their entire reputation on this. The design process doesn't end at handoff — it runs in parallel with engineering, adjusting as technical constraints surface.

A shared component library, when it's properly maintained, is a contract between design and engineering. A designer adds a new pattern to Storybook on Wednesday, a developer ships it Friday. When it's neglected, you end up with five slightly different dropdown implementations scattered across the same product. Sound familiar?

The Honest Takeaway

Legacy modernization and UI redesign aren't parallel tracks. They're the same track. Treating them as separate efforts is the most expensive mistake on this list.

The visual layer and the technical layer evolve together, or the whole thing stalls. Start conversations between design and engineering before wireframes exist. Understand the backend as a constraint that shapes design decisions. Build incrementally. Invest in the design system as infrastructure. Measure success in shipped, working improvements — not presentation decks.

The companies doing this well aren't always the biggest or best-resourced. They're just the ones where designers and engineers are solving the same problem at the same time. That's actually most of it.

The rest is uncomfortable conversations about what the codebase can actually do. Good luck with those.

Written by DesignCrowd on Friday, July 31, 2026

DesignCrowd is an online marketplace providing logo, website, print and graphic design services by providing access to freelance graphic designers and design studios around the world.