I'm presuming the following things:
- the key pairs of the trusted root CA's will be regenerated;
- the root certificates in PKI-2 will have a new Distinguished Name;
- the private keys of the issued certificates won't be changed;
That however means that you'd still have to renew each certificate directly below the root certificates. If those certificates retain their original identification (subject distinguished name) then the certificates directly below those do not have to change, as the issuer identification of those certificates can remain unaltered. Also, the algorithm output of any of these certificates will remain valid.
This will still leave you with a problem though. Generally we use specific protocols to generate signatures. Let's use CMS as an example. These signature protocols will also include a list of certificates, so any verifier is able to create a valid chain up to a trusted root certificate. If these remain identical then the certificate chain cannot be build, as the new certificates below the root are not available. So you'd have to include those or source them from outside the CMS message. And - obviously - the verifiers also need to update their trust store with your new root.
Generally software should always try and build chains until they find a certificate that is in the trust store. However, I'm not sure if all software will always do that. It may be that it finds a partial chain using the old certificate and give up at that point. So if possible you should also remove the old certificates from the certificate store inside the signature container.
Note that there are serious issues with key pair reuse. I would at least make sure that they keys are not thrown away once the certs expire, and that the validity date in the new certificates doesn't expand past their original due date. I'd strongly suggest going through the original CA policy and check if they key pair reuse is allowed by it (in your case, as it is an internal policy, you may have some slack there).