Let’s say you have a single server AD RMS deployment and you want to migrate (move) it to a new server without losing existing permissions.  What is the best way to accomplish this?
 
It can be very simple, as long as the following two conditions are met:
 
1)     The Intranet Cluster URL is a fully qualified domain name (FQDN)
2)     The database is located on a separate server
 
If these conditions are met, simply build a new server to replace the existing AD RMS server, install the AD RMS server role on it, and elect to join the existing cluster. You will be prompted for information such as the database server FQDN and the name of the Configuration database. The name of the Configuration database will be DRMS_Config_IntranetClusterFQDN_PortNumber where PortNumber is 80 if you are not using SSL or 443 if you are using SSL. Any periods in the FQDN are replaced with underscores.  An example might look like this: DRMS_Config_adrms_contoso_com_443, where the cluster name is adrms.contoso.com and it is using SSL.  Once AD RMS is installed and ready on the new server, update DNS to point to the new AD RMS server and turn off the old system.  Do not decommission AD RMS in the old server, as this is only appropriate for when you are removing all AD RMS servers from your organization.  Also, do not destroy the old system until you have tested the new AD RMS server by obtaining Rights Account Certificates (RACs), Client Licensor Certificates (CLCs), and End Use Licenses (EULs).
 
If the two conditions above are not met, your best option is to create a brand new AD RMS installation using a FQDN for the Intranet Cluster URL and a separate database server (also use a FQDN when specifying the name of the database server).  Then, export the Server Licensor Certificate (SLC), private key, and templates from the existing server and import them to the new server as though creating a Trusted Publishing Domain and a Trusted User Domain. You will then have to set registry key overrides on the client computers so that your previously protected content is still accessible. Turn off the old system and test the new system and the Trusted Domains before destroying the old system. Note that if you have published the Service Connection Point in Active Directory you will need to deregister and reregister the Service Connection Point from the new system. A simpler approach is to deregister the Service Connection Point from the old system prior to provisioning the new system and register it from the new.
 
For more information on Trusted User Domains see the TechNet article Trusted User Domains (http://technet.microsoft.com/en-us/library/dd983944%28WS.10%29.aspx). For more information on Trusted Publishing Domains see the TechNet article AD RMS Trusted Publishing Domain Considerations (http://technet.microsoft.com/en-us/library/dd772677(WS.10).aspx).