What to do with aging software infrastructure
Although technology is getting better and it's easier to develop software in recent years than long ago, debugging them hasn't gotten any easier. If things don't work there is work for me. Although it's many times easier to just patch or hack a system, it's important to consider to substitute and interface whole new subsystems. Many times new life can be introduced into an aging software infrastructure while preparing for complete refactoring.
It's very interesting to me how translating software from one operating system to another is done very seldom even though there is a lot of knowledge in the existing software which are lost through a new rewrite. Translation of software is hard, and it's even harder to shed features that should not have been there in the first place. Removing features to gain a product which implements a few things well rather than a set of features not so well is essential to keeping aging software from becoming a major maintenance problem.
The only way to migrate software is with a good plan and no fear. Just start converting small subsystems one at a time until the whole system is initially converted. It might not immediately work all the way but it's the first necessary step. Then you need to go through and repair the converted subsystems one at a time. Automated testing helps a huge amount in this process, but also will take additional time if such doesn't exist. There is definitely a tradeoff.
The important thing is to always look at the software as one whole thing. All servers, routers, computers, browsers and networks should be considered as part of the implementation. It's important to know the weak spots in the system even if those are not located within the software you control. It might be possible to do things another way to remove weaknesses external to you, but you need to know where they are an have consideration for them.
Software runs at all levels of your stack; from hardware drivers written in C and assembler, to middleware written various higher level languages - with customization such as SQL server for example, to end user software like desktop thick clients, mobile clients or internet browsers. They are all part of the infrastructure your system relies on and therefore are part of your implementation. It's not very useful to tell an end user if the browser they are using is not one of the ones you prefer. It would be better to design your system to degrade on sub-par browsers rather than not working at all.