In the history of complex systems, a recurring development process pattern exists in which a new approach, design, or architecture is introduced to partly replace existing functionality that is attaining obsolescence. The reason for this partial line of attack is that a complete replacement of existing functionality is deemed too invasive and risky. The intention is that, at the next occasion (typically a development cycle), the remains of the obsolete implementation will be fully replaced by the new approach. It is not until this time that the functional and architectural benefits of the new method can be reaped. The practice is that, when the next project emerges, great emphasis is placed on a few new functional features that must enter the market in the shortest time possible. Promises or agreements that the old hat must be gotten rid of are quickly traded for seemingly more attractive short-term goals. What seems to be overlooked is that each time a new dual-track is entered, maintenance costs rise. What is much worse is that future development is curtailed because whatever is developed in the new design must remain compatible with the old implementation with which the new line is condemned to cohabitate in the same or similar applications. When this cohabitation is forced to go on for an extended time, the new implementation starts to suffer from its (potentially advantageous) adaptability and starts to adopt the idiosyncrasies of the components it was designed to replace. In our product, an MR scanner, this was evident from the striking fact that there evolved two distinct ways in which the scanner could be operated. In order to facilitate ease of use and thereby increase throughput, a solution evolved that automated a lot of tasks that were inherently performed by the operator. This new path, termed ExamCards, however could not provide the complete functionality that was present in the old way of operating the system,the ScanList environment as it was termed. This led to the fact that the operator had to switch between these environments in order to exercise the complete set of options provided. Architecturally this was a nightmare, since solutions or software that had to be built into the system (for the introduction of new functionalities that the market demanded) had to support both of these worlds. Moreover, as in typically large software systems, there exists a lot of history and legacy that must be carried forward. The presentation will focus on experiences in dealing with the architectural challenges of the described system.