Our back-end servers (Redhat 5,6 mostly) are very outdated, and are not connected to the Internet for security reasons.
I'm looking for the best strategy to update them, without connecting them to the Internet.
Updating an offline machine means finding a way to present the updates to that machine (this will most probably involve an external hard disk or USB stick, to move the files from online machines to the offline systems).
In generic strategy terms, you have the choice between the three following solutions:
Put the systems briefly online, behind some well-configured firewalls which will let download requests pass, but no more.
Download all relevant update packages, and transport them (with an offline medium, such as a USB stick) to the machine to upgrade.
Don't upgrade: the systems are offline, so they don't need security updates.
The first one is easier, but (arguably) the second is safer. In the case of RedHat systems, this is normally a matter of creating a local repository; a lot of information can be found online with some simple Google requests. See for instance the RedHat documentation itself.
The third strategy (do nothing) is the easiest to implement, but requires some thinking. Basically, you first have to carefully decide with yourself whether an update is actually mandated. There is no such thing as "outdated" in general. If you need some newer functionality, or newer software to accommodate newer hardware parts, then of course some update will be needed. However, this is still a question which deserves some thorough thinking.
It is very hard to answer your question because it mostly is "how do I fix a broken state" ? The answer depends a lot on the specifics of your installation and requirements.
However, recovering will start with fixing the real problem first: making sure you either can (and will) patch your servers in the future or making sure you will not need to.
For that, you need to identify the reason why you're not patching. It can be resources (you don't have the time to test and deploy patches), requirements (you're depending on an application that require a specific version of your platform) or simply bad planning (you have never properly tested your updates and were "burned" by a bad update once, leading to a "no patch" strategy).
After you have identified the cause of your problem, you should design a fix. It usually implies designing a testing strategy, improving documentation and processes and allocating resources.
Once that is done, "how to patch" should have been solved already. One of the simplest way to migrate from the current state to a new state where patches are applied it to reinstall the servers (safely) and migrate the application. if you have prepared the documentation, it should be a rather simple step (although if you need high availability, it might be delicate to implement).
Finally, there is the special case when you decide that you actually don't need to (or can't) patch. In this case, simply document properly your situation (including relevant statements from decision makers).