You have to weight that cost, and the ongoing cost of that approach against migrating to something new.
As pre-canned software becomes more flexible and cheaper, and talent to tweak it into what you need, simply tossing out a perfectly functional system starts to make more sense.
Your first sentence makes a certain amount of sense, but your second sentence indicates a lack of appreciation for dependencies.
Most people look at the cost of a system as the price of the servers, the price of the software, the cost of the project to implement them, and the ongoing maintenance contracts. What they often don't consider or fully understand is the impact to people and process. Changing a system means retraining the people who use the current process; changing paper forms, supplies, expectations, timings. There may be things like quality assurance steps built into the current process that the system builder is completely unaware of, such as "between filling out form 37-stroke-B and submitting form 52-mark-K, we have the testing team pull out a sample for evaluation."
Then again, we've got crap like SAP as a pretty good encouragement to pour more money into that old mainframe and hold off for a few more decades..
If SAP is progress, that can only mean that the prior process was done by filling out forms in Klingon using wax crayons writing on saran wrap in an iron foundry.