Problem: To make an exact copy of the production org into another fresh production instance.

Possible Solutions: I have thought of a few possible solutions, please let me know if there is any better solution available.

  1. Create an unlocked package of the existing production org, and then install it in the new instance.

  2. Copy everything into vs code and then deploy to other org's any sandbox by copying this vs code's metadata to a new project (of new instance).

  3. I have also found a link with a similar problem, but it is a bit old and now I believe there should be some advanced solutions available Copying metadata and code from one Production org to another

Also, wondering what could be the possible fallouts in the first 2 solutions.

I'm NOT looking for any paid app exchange solutions.

NOTE: My existing production org is already having communities, SSO, manage package, (having same integrations as it is in existing org is optional so we can assume that the existing org is having no integration), org edition is unlimited(so please let me know what functionalities I can not move in any way possible)

2 Answers 2


It depends on how frequently you need to do this.

Unlocked Packages are great for maintaining multiple orgs with metadata in a Git repository for backup, along with the ability to revert most metadata changes to an earlier version with a simple command. It's the ideal use case for most customers.

The downside to Unlocked Packages is that it will force even admins to learn how to use either Terminal commands and/or VS Code, or risk their changes being overwritten. I actually see this as not much of a downside, as it makes it easier to replicate orgs with expert precision to test out changes before destroying a Sandbox or Production trying.

The one-time download to VS Code is a decent option if you just need it once. It tends to be really frustrating, as you won't know you're missing metadata until the deployment fails. Unlocked Packages fail a earlier, during the upload process, so you'll know you have problems before you're in the middle of a deployment. The upside, though, is that you're wasting less time on something you'll never use again (Unlocked Packages).

Other than that, paid solutions are really your only option. I know that budgets are tight these days, but there are many respectable products out there that are relatively inexpensive.

One such example is Gearset, which is what we use internally to migrate changes between orgs, and it's a decent product. You can easily compare two orgs and migrate any or all changes with just a few clicks, and it can even apply those changes to a Git repo for you to back up.

Note: this is not a product recommendation as such, just one I have some exposure to. Always do your own research and comparisons before making any purchases.

Finally, please note that there is no way to make a complete copy of a Production Org to another Production Org. Some settings can't be copied by Metadata Deployments. The list of things you can copy is maintained in the Metadata Coverage Report. You should review this list before making a choice on how to proceed, as even AppExchange apps can't do things that aren't on this list. No matter which approach you take, you'll need to check the report link above to see what you'll have to manually configure.

Salesforce used to have an internal "clone org" function many years ago, but it seems like they've abandoned that. You can make perfect copies of a Production Org into a Sandbox Org, but not another Production Org. Creating a new Production Org from another will likely be a time-consuming process.


Unlocked packages are something to consider if you want to break your monolith into modules. It is a project in itself if you have a complex application with a lot of metadata.

If you want to merely copy from one org to another then using Salesforce CLI and leveraging mdapi commands to retrieve and deploy is recommended.

You can retrieve it by constructing package.xml. This is not going to be an easy win because we lack officially supported tools to do this on the platform.

One tool that makes it easy to construct a package.xml is an online tool here.

The other alternative is to make an unmanaged package and add all metadata in the org to it and retrieve it by the package name. Check the last few parts of the video here on how to approach it.

The other alternative is there is an open-source project in Node.js that helps to retrieve all the metadata.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .