There is no easy answer to this dilemma. The old code still works. We like it. It's just that it's not compatible with the new version of the operating system or a new multicore chip. The new code costs money. We can usually fix a number of glaring problems with the old code, but who knows what new problems might appear?
Developer dilemma No. 5: SQL vs. NoSQL
There is one big challenge for the database administrators of the world: stick with tried-and-true SQL or switch to trendy NoSQL where everything is bigger and ready for endless streams of data.
The new NoSQL databases sound attractive. They can be much faster than older databases, and they often force users to avoid many of the problems that caused so much trouble in the first place. JOINs, for instance, can slow down a database if the schema gets too complicated. NoSQL tosses them out the window along with many parts of the schema. You can store any key-value pair you like, and the NoSQL database will come up with the answer.
But if you look closely, the NoSQL databases aren't always so wonderful. First, they often don't offer guarantees that the data will be recorded. It probably will be OK, but not if something happens to a hard drive or a computer in the cluster. Some of the newer NoSQL options from companies like Oracle allow you to ask for a transaction confirmation, but your code will need to twiddle its thumbs and wait just like the code that uses a SQL database.
There are deeper issues. Many of the speed problems came about because programmers didn't think about the subtle effects of SQL. The way you structure your tables and queries can make a big difference in performance. Linking together multiple tables and forcing the database to JOIN the information slows things down.
But if you try to accomplish the same thing with a NoSQL database, you'll often be writing data in and out of multiple places and hoping it will all stay consistent. You get to do all of the work of JOINing disparate sections of the database, and that probably means you'll pay the cost in speed. If you are aware of this and are able to think through the trade-offs when designing code, you'll be OK. But if you're not, you may find that your code is even slower and buggier. The database won't enforce the transactions, and you'll need to do it yourself.