The biggest risk in a legacy portal redesign is not that the new version looks dated in three years. It is Monday morning of week one, when an operations team that could process two hundred orders a day in the old system can suddenly manage ninety in the new one. Everything you shipped is better on paper. Throughput fell by half anyway, and now nobody trusts the project.
Consumer redesigns are judged on whether new users understand the product. A B2B portal is judged on whether existing users, who never chose it and cannot avoid it, can still hit their numbers on day one. That single difference should reshape how the whole project runs.
Why these are harder than they look
Your users are already fast
Somebody has been in this system eight hours a day for six years. They do not read the labels. They know the third row of the second menu, they type through fields without looking, and they have a keyboard path through the order form that takes eleven seconds. A cleaner interface that takes fourteen seconds is a downgrade to them, no matter how much better it looks in a case study.
The workarounds are the requirements
Every old portal has a shadow system around it: a spreadsheet that holds the fields the software never added, a naming convention in a free-text box that encodes something the schema does not support, a person who knows which report to run at month end. Those workarounds are not user error. They are unwritten requirements, and if the new build ignores them the spreadsheet simply survives the redesign and now you have two systems.
The edge cases are the business
In consumer products the edge case is a rounding error. In B2B it is the customer who gets bespoke pricing, the order that ships from two warehouses, the client whose invoice has to be split across cost centres. These are usually the most profitable accounts. A redesign that handles the clean path beautifully and cannot express the messy ones will be rejected by exactly the people whose opinion carries weight.
Start by watching, not by surveying
Surveys tell you what people think the process is. Sitting behind someone for two hours tells you what it actually is, and the gap between those two is where the real design work lives. What I look for:
- The screens they keep open all day. Those are the product. Everything else is secondary navigation, whatever the sitemap says.
- Where they leave the system. Every hop out to a spreadsheet, an email or a chat thread is a feature that does not exist yet.
- What is written down near the desk. Sticky notes and cheat sheets are a map of everything the interface fails to make obvious.
- The steps they do without looking. That is muscle memory, and it is the most expensive thing in the room to break.
- Where they slow down or hesitate. Hesitation marks a decision the system is not supporting, which is usually where the redesign can genuinely win.
Count clicks and seconds on the two or three tasks that dominate the day. Those numbers become your acceptance criteria later, and they are far more useful than a satisfaction score, because “the new portal is nicer” and “the new portal is slower” can both be true and only one of them ends the project.
What to preserve, what to change
The instinct on a legacy rebuild is to modernise everything at once. Resist it. Split the system into what carries muscle memory and what is simply old.
| Preserve | Change freely |
|---|---|
| Keyboard paths and tab order through high-volume forms | Visual design, spacing, typography, colour |
| The organisation’s own vocabulary, even where it is technically wrong | Layout of screens people visit occasionally |
| Deep links and bookmarked URLs | Navigation structure, if you keep old routes redirecting |
| Exports and report formats other systems consume | How reports are generated and scheduled |
| Record identifiers people quote on the phone | How records are searched and filtered |
| The order of fields in the highest-volume workflow | Everything about the low-volume workflows |
The vocabulary point earns particular attention. If the business has called something a “docket” for twenty years, calling it a “delivery note” in the new portal costs you weeks of confusion in exchange for correctness nobody asked for. Design the system in the users’ language, not the data model’s. The same discipline applies to the screens themselves, which I wrote about in B2B dashboard design principles.
Ship in slices
Big-bang cutovers are how you get the week-one cliff. The safer shape is to replace the portal one workflow at a time, starting with something high-value and low-risk, and to let the old and new systems run side by side while both are true.
Practically that means new screens for one workflow, links between old and new that feel continuous, one team using it before everyone does, and a way back to the old screen for the first few weeks. Keeping a visible escape hatch feels like an admission of failure. It is the opposite: it removes the fear that makes people resist the whole project, and the day nobody uses the escape hatch is your real proof that the new version is better.
Sequencing the rollout is also what stops the timeline collapsing under the usual causes, which I covered in how long a build actually takes.
What nobody budgets for
Four items that reliably surface late on this kind of project:
Data that does not fit its own schema. Ten years of free-text fields holding structured information by convention. Someone has to decide what happens to the records that break the rules, and it is a business decision rather than a technical one.
Permissions and roles. Legacy systems accumulate exceptions, and the real permission model is rarely what the documentation claims. Map it from the live data before designing the new one.
Integrations you find out about later. Something is scraping a report, a partner posts to an endpoint nobody documented, a warehouse tool polls a file share at 5am. Ask what else touches this system, then ask twice more.
Training material and internal comms. Screenshots in the handbook, the induction deck, the support macros. All of it goes stale the day you launch, and updating it is the cheapest insurance the project can buy. The general version of this checklist is in the website redesign checklist, and the portal-specific items sit on top of it.
Frequently asked questions
How long does a legacy portal redesign take?
Discovery and a first workflow, three to four months for a mid-sized portal. The full replacement usually runs a year or more, which is exactly why slicing matters: you want value in production long before the last screen is done.
Should we redesign or rebuild from scratch?
Different questions, and they need not be answered together. A new interface over the existing back end is often the fastest route to relief, because it removes the daily pain without a data migration. Rebuild the back end when it genuinely blocks the business, not because the code is old and unfashionable.
How do we get buy-in from users who like the old system?
Involve the fastest, most sceptical user first rather than last. They know the workarounds, they will tell you exactly what is wrong with your prototype, and if you win them the rest of the team follows. Excluding them until launch guarantees an opponent with credibility.
What do we do about the spreadsheets people use alongside the portal?
Read them before designing anything. Each one is a specification for a missing feature, written by the person who needed it. Some should become part of the product, and some are fine as spreadsheets. Deciding deliberately beats discovering it after launch.
How do we know the redesign worked?
Task time and throughput on the workflows that dominate the day, measured before and after. Support tickets and the number of people who quietly go back to the old route are the honest secondary signals. Satisfaction scores are the least useful thing you can measure here.
If you are staring at one of these
Legacy portals, ordering systems and internal tools are most of what I work on, usually for distribution and B2B SaaS teams where the software is the operation rather than a shop window for it. If you are planning a rebuild and want a second opinion on the sequencing before anyone commits to a date, send me the outline. There is more of this kind of work in my case studies.
Planning a website or product design project?