How do you redesign legacy enterprise software without upsetting users?

Treat users' habits as requirements. Find the habits that carry real work, keep them stable unless the payoff for changing them is large, test the change with people who know the old version, and move accounts across in stages while the old version stays available. The rest of this guide shows how to do each step.

This guide covers the user side of modernising a legacy product. It assumes you have already decided, capability by capability, which ones to redesign. That decision is the subject of Preserve, redesign, replatform or retire, and this guide picks up where it stops.

What are users actually attached to?

"Muscle memory" is shorthand for several different things, and each one breaks in its own way. Sorting habits into kinds shows what a redesign will actually disturb. The kinds below are a working classification from practice, not a published taxonomy.

The first row has experimental support from a neighbouring setting. Scarr and colleagues (CHI 2013) transformed a spatial interface in several ways: shifting, scaling, rotating and changing perspective. Most of the transformations did not strongly affect performance, large rotations did, and a stable layout that was scaled beat one that was reflowed. That is a set of controlled experiments on a spatial layout, not a study of an enterprise product. Read it as a reason to check whether a responsive redesign reflows content people have learned by position, not as a rule.

The last row is easy to miss, because much of it sits outside what the product team sees. In regulated or process-heavy customers, the screens may be pictured in procedures and training material. That is an inference from how such customers work, so ask rather than assume.

Why do users resist a design that is better?

One documented reason is that the better design arrives on top of a habit. Polites and Karahanna (MIS Quarterly, 2012) found that habitual use of the incumbent system, rationalising the cost of switching, and a sense of sunk effort together build inertia. That inertia led people to resist the new system even when they recognised its advantages, and it coloured their view of how easy the new system was to use.

Wood, Tam and Guerrero Witt (2005) studied a related mechanism outside software. Students who changed universities kept habits such as exercising, reading a newspaper and watching television only when the context in which they performed those habits stayed similar. The authors' account is that habits are cued by their surroundings. A redesign changes the surroundings, so what you leave similar plausibly matters as much as what you improve. That is this guide's inference, not a finding: the students' habits were exercise, newspaper and television, not software use.

Two practical consequences follow, and both are judgements built on this evidence:

• Early complaints are a biased instrument. Inertia colours perceived usability, so a loud first week neither proves the design wrong nor excuses ignoring it. Pair sentiment with behaviour: how long tasks take, where people make errors, whether they go back to the old version.
• A temporary drop in speed is to be expected and planned for. Scarr and colleagues (CHI 2011) describe a performance dip when users move to a new technique. They say it can deter people from switching and colours first impressions, and in their study a large dip would have led participants to stop using the technique had they not been required to. Their subject was voluntary adoption of faster techniques, not a forced redesign, so treat it as the shape of the problem and not a measured size for yours.

Which habits should you keep, and which should you change?

Rank habits by how often they run, what a failure costs, and whether they live outside the product. Then apply three rules.

1. Keep stable the few high-frequency actions, the names people say aloud, and everything that lives outside the product. Where a link, a saved view or an export format must change, convert it, redirect it or publish a mapping.
2. Change a habit when it exists to compensate for structure that no longer works. A person who checks a result in three places because the product never shows the real status is working around the product, and that is worth redesigning.
3. Charge every change to a budget. Each altered name, moved action or new state is relearning you are asking customers to pay for. Spend it where the task improves.

Tcules's Product Redesign page describes a continuity ledger kept beside the redesign. For every redesigned capability it records what existing users have learned, what is failing, what will change, how people and data will transition, and which evidence must permit the next rollout stage. The live page presents the ledger as a decision record that keeps continuity decisions explicit during implementation. This guide uses it as a way of making the relearning budget visible before the first release.

Tcules's work with Benchmark Gensuite illustrates the approach on a long-running enterprise suite. The case study says the platform could not pause for a screen-by-screen redesign, so the work began in the shared component layer and was then applied to one high-use feature, the scope selector. The redesigned selector gave three needs their own views: browsing the organisational hierarchy, returning to recent and favourite areas, and finding sites nearby. Benchmark's technical leadership is quoted: "For established users, familiarity and consistency are important parts of efficient workflows." The case also states its limit: when it was documented the modules had not reached customers, and no adoption metrics or commercial outcomes were available.

How do you test a redesign with people who know the old one?

Test with existing users and new users, because they answer different questions. New participants show whether language, structure and actions can be understood without learned workarounds. Existing users show where a renamed object, a moved action, a converted draft or a new state conflicts with work they already do. Tcules's Product Redesign page draws the same distinction.

Four practices make the existing-user sessions more useful. They are working practice, not findings from the research above.

• Use their own saved work and a real task from their week, not a script. Converted drafts and old saved views are where redesigns break.
• Run the same task more than once. A first attempt measures the dip and a later attempt shows whether it recovers.
• Treat a slowdown that persists on later attempts as a design problem. Treat one that fades as relearning, and decide whether the benefit pays for it.
• Include support staff and customer administrators. They know the exception paths, and they know which scripts, extensions or reports depend on the current screens.

How do you roll it out in stages?

Staged rollout comes from sources outside interface design, so the useful move is to borrow the mechanism and adapt it.

The UK government's service manual describes starting a private beta with a limited number of invited people, then opening to everyone, and says that when you replace a legacy service you should keep the legacy service running until the new one moves into its live phase. For its tax disc service in 2014, the Government Digital Service, working with the DVLA, first showed the new service prominently to 20% of visitors, with the rest seeing it as a secondary option, and later moved to an even split. The stated aim was to encourage more people to the new service in a controlled way, without overwhelming it, while putting it through its paces.

Google's site reliability engineers define canarying as a partial, time-limited deployment of a change and its evaluation. They stress that the canary population must be representative and observed long enough, and that its metrics should be kept apart from the control group's.

Interface changes add a complication. Microsoft's strangler fig pattern guidance notes that when you run parallel versions, clients must track which version contains each feature, and that the transitional façade layer carries temporary infrastructure costs. In a user interface the client is a person. A visible seam between old and new is something someone has to learn.

The table is a working summary from practice, not a research finding.

Three judgements, drawn from practice rather than from the sources above:

• Choose cohorts by account or team, not by individual, because teams share procedures and training.
• Schedule around the customer's calendar. Avoid their reporting and close periods.
• Give parallel running an exit rule: criteria for retiring the old version and a date, or the old version stays by default.

What should you measure while it rolls out?

Decide before launch what you will watch and what result pauses or reverses a stage.

• Time and errors on the top tasks, split between experienced and new users, on first and later attempts.
• Reversions: how many people switch back to the old version, and what they say.
• Support contacts by theme, compared between the new cohort and the control group.
• Breakage outside the product: failed links, saved items that did not convert, exports that another team reads.
• The pause rule itself, written down and agreed with whoever can say stop.

The thresholds are yours to set. Nothing in the research above supplies a number for how much change a user base tolerates.

What the evidence does not tell you

The habit research comes from controlled experiments on interface layouts and shortcut adoption, a survey of students who changed universities, and a study of technology adoption. The rollout mechanisms come from government service guidance, one 2014 government blog post, and software engineering documentation; none of them measures whether staged rollout reduces user upset. The sources reviewed for this guide include no controlled study that measures how much interface change an enterprise user base absorbs, or how long recovery takes, so the practices here are judgements built on adjacent evidence. Where the evidence is about a neighbouring question, the text above says so. Treat the first rollout stage as a test of those judgements on your own users.

Where this work sits

This is the design-led half of modernisation, and it applies after you have chosen which capabilities to redesign. If you want help applying it to a product whose customers already know it well, see Tcules's Product Redesign work.