Maintain PCI Compliance on LAMP Server with Outdated Repositories

Your definition of "rotating keys" is correct. You need to decrypt the data with the "old" key and re-encrypt it with the "new" key. There are plenty of shops that do this on an annual basis, and yes - it's a lot of work and best done by an automated program (you can probably write your own tool - I'm not aware of any third-party ones but I'm sure they exist).

<Rant>

The interpretation of the PCI-DSS 2.0 requirement 3.6.4 "Cryptographic key changes for keys that have reached the end of their cryptoperiod (for example, after a defined period of time has passed …" as "You have to rotate keys annually or the world will end" is shortsighted, and in my/my auditor's opinions incorrect: If you are using a sufficiently strong algorithm (e.g. AES-256) and have no known breaches of your key rotating your keys doesn't provide you substantially better security - in fact it creates a new exposure (the old key needs to be made available to a program for as long as it takes to decrypt/re-encrypt your data - Even if the machine doing that work is secure it still involves putting the key in more than one place).

Note that if you want to make this argument successfully you need two things: An auditor that has a basic understanding of cryptography, and a defensible policy that flies in the face of NIST publication 800-57 (specifically the "recommended cryptoperiods" table). Our policy for example requires AES-256 (which is free from practical attacks, and would take forever to brute-force) and forces a key rotation when someone with direct access to the keys is terminated (key sysadmin staff, certain C-level officers).

</Rant>

The last time I read the PCI standards, they had the isolation requirements pretty well stated (the technical term in PCI language is to reduce the scope of the PCI compliant environment). So long as those flagrantly un-compliant servers have zero access to the compliant zone, it should fly. That would be a network segment that is fully firewalled from your normal network, and the rules on that firewall are themselves PCI-compliant.

We did much the same thing ourselves at my old job.

The key thing to keep in mind is that from the perspective of the PCI-compliant zone everything not in the zone is to be treated like the public Internet, no matter if it is also the same network that also warehouses your corporate IP. So long as you do that, you should be good.