Working with a legacy application usually brings with it various problems that need to be overcome. This is a part of the challenge when working with a legacy system. Perhaps most importantly, a legacy application tends to be difficult to maintain and extend. It may use older, possibly outdated, technologies and it may not follow best practices for software development.
A legacy application tends to be older, and over the life of the project many different developers may make modifications to it. Software entropy, or disorder in a software system, increases over time. This concept comes from the Second Law of Thermodynamics, which states that the level of entropy either stays the same or increases but it does not decrease. As modifications continue to be made on a codebase, the code can become brittle and messy, resulting in spaghetti code. If you have ever needed to make a modification to a legacy application but were afraid of breaking something, you know firsthand the difficulties of dealing with a legacy application.
A legacy system will almost certainly bear some amount of technical debt. Any design decisions that have been made for an application, in which an easier, quicker solution was selected over one that was a cleaner solution but would have taken longer to implement, incurs technical debt. Similar to a financial debt, technical debt is the cost of these decisions, such as the cost of any rework necessary to improve the system. Technical debt increases software entropy.
Deciding to incur technical debt is not necessarily a bad thing. Sometimes it makes sense to take the easier approach. For example, you may want to complete a feature faster to take advantage of a market opportunity. Whatever the reasons are, though, a software architect should realize that a legacy system will come with technical debt.
Some legacy applications rely on older versions of operating systems, other software, and/or hardware. These environments can become increasingly difficult to maintain over time. It also increases the possibility of vulnerabilities if security patches are either not available or not applied.
A legacy application may be one that has been inherited from another development team, who may no longer be available to answer questions about it. This may lead to a general lack of knowledge about the system. Documentation and unit tests for a legacy application may be lacking, making it more difficult to gain an understanding of the application and to make changes to it.