@My2ndLovE , following up to check if you had a chance to review the reply above.
Please note that "move" and "copy" are 2 different scenarios. In move - the resource group is moved to a new subscription (like cut and paste) however, with copy, a copy of resource group is created (of course with different names based on the requirement).
If the source and target subscriptions are under same tenant, you may follow the step as suggested by Vinodh in the response above - Move resources to a new resource group or subscription.
However, if the source and target subscriptions are not under the same tenant, the second step can be used - [Move of resources between 2 different tenants (Subscription A in tenant A and Subscription B in tenant B)](https://learn.microsoft.com/en-us/answers/questions/505287/move-of-resources-between-2-different-tenants-(sub).
Note that the steps in the second options are more prone to errors, therefore it is recommended to have backups/templates etc handy when performing such move as a backup plan.
The scenarios discussed above are for move scenarios where the resources along with the data moves to a new subscription.
However, if the requirement is to create a copy of resource group and its resources in another subscription, the step above would not work. The only option available is to export template with parameters, update the parameters with unique names, where required (this might not be required for all resources, for example VM name need not be unique. However, for certain resources, the names need to be unique for example sql server name).
If the resource group contains many resources, exporting the template of the resource group itself will provide you with a huge template/parameter file, which might not be easy to work with. Instead, I would suggest examining the resources in this RG, and then exporting the template from one resource at a time. This would be more manageable to work with. There is no other away to perform this task, except manually - either using template, or through script if you know exactly what config needs to be set or through portal.
For future deployment, I would suggest following the Infrastructure as a Code model to ensure that resource creation is documented as script/file and can be deployed to the same or different subscription whenever required. Alternatively, you could also use Azure CLI/PowerShell to create resources -- then document each command for the resource in a source control repository. This would ensure that you have all the cmds handy if the same resource with configuration needs to be created again.
Hope this helps.