A legacy system is more than old software. Its architecture and accumulated constraints can make changes difficult, while the people and ways of working around it make modernization a social challenge too. Systems built over years or decades rarely have a quick fix. Set expectations for sustained work, delays, and discoveries that may change the plan. section 2.1.2 section 2.1.3
When a simple improvement reaches deep into the system
A government service gained a better website but could not capture new information or show details unavailable through the legacy system’s API. In another service, users could not enter enough information about their cases: a character limit was enforced by an XML schema and two databases. Neither problem could be solved by changing the page alone. section 2.4.1 section 3.1.5
Beware of bolt-on modernization: a new interface can improve the experience while remaining coupled to systems and databases that limit the product. That may be a useful transitional step, but it is not a substitute for addressing the underlying constraints. When a requested change seems small, trace what the interface depends on before promising a quick solution. section 2.4.1 section 3.1.5
Modernization must also compete with bug fixes and new features. Keep its value and priority visible; otherwise familiar work can absorb the time set aside for it. If only a few people understand the legacy system, transfer that knowledge rather than assuming they can work effectively across two teams indefinitely. section 16.3.5
