If a group of users is accustomed to a complex software system, and you’re designing its replacement, how simple can you design that replacement to be? 
Simpler software—software that is discoverable, easy to learn, and easy explain to others—frees its users to focus on tasks that add value. It may also frustrate former expert users as they suddenly find themselves less-than-expert users of the new tool.
If the software you’re replacing is so complex that it requires a dedicated group to mop up the errors of other users, then the impact of a very simple replacement is potentially disruptive. The users’ jobs are going to change.
The discipline of change management would advocate using a structured approach to transition individuals and teams to the new software, in a controlled manner, by following a pre-defined framework with, ideally, only reasonable modifications. But for an in-house UX-design team tasked with replacing a complex legacy system in one fell swoop, questions arise:
- How much workflow change is reasonable? How much process change is reasonable? How much is too much?
- How much organisational restructuring will a simpler system trigger? Who prepares the company’s other teams for significant change and possibly for job reassignment?
- Should any inefficiency be deliberately ported from the legacy system into the new system, merely to reduce the scope of change, for the comfort of existing users or to reduce the soft costs of workplace disruption?
In a business environment, where data—numbers—often have more sway than wireframes and design walk-throughs, one way to prepare stakeholders (that is, managers) for significant change is to test the designs and prototypes early and to measure their impact on user performance. User-experience designers and usability researchers then need to communicate their projections far enough in advance to permit the user groups to plan for change.