You will need to resign the subordinate CA (CA-Subordinate) with the new Root CA (CA-Root) for the certificates issued by the subordinate CA to remain valid. You'll then need to distribute that re-signed subordinate CA certificate to all your subscribers, so that they present the correctly signed subordinate CA certificate in their TLS handshake.
To do this, you will need the original certification request file which was generated by the subordinate CA just before your original root (CA-1) signed it. This is normally placed on the root of the C:\ drive of your subordinate CA when you build it (the file is named after the CA name and ends in .req normally). Copy this file to your new root CA (CA-Root) and start the CA management console. From there, click on the CA's name, select All Tasks from the Action menu and choose Submit new request... In the Open Request File window navigate to the .req file and click Open. The request will now be visible in the Pending Request queue, which you can review. Verify that the request is the correct one for the current subordinate CA certificate (hint: compare Subject and public key), then once you're happy, issue it.
Your last task will be to distribute this re-signed subordinate CA to all subscribers, using whichever method you used originally.
That is the least of your worries though, as you'll need to distribute your new root CA (CA-Root) certificate to all your relying parties. If you're in a Windows domain, then group policy can distribute it for you, otherwise it could be a laborious process.
If you distrust the original Root CA (CA-1) then you will need to ensure that its certificate has been removed from the trust-anchor store of all relying-parties. You will also need to ensure that all subscribers have swapped the old subordinate CA certificate for the new one before you do this.
