I have been working under an organization's salesforce instance for a little under a year now and have created custom objects, API endpoints, LWCs, and more.
There has now been a a structural change where there will be two organization salesforce instances and all of my work needs to be transferred to that new organization.
Just to note, I am NOT talking about using change sets to transfer changes between one Salesforce instance to another with the same organization. I am talking about transferring changes between one organization's salesforce instance to another organization's salesforce instance.
I know that this is not possible through change sets. From some research, I've found something called the ANT Migration Tool, but it states that it's a utility for moving meta data from a local repository to a salesforce org, and I'm not sure how you would get your work down into a local repository.
I do use VSCode's SFDX Extension for my work, but when I authorized with my organization, did that pull down all the meta data? Can I just authorize my SFDX project with another org and upload to that org?
Best Answer
You have one. If you're working on metadata in VS Code, you're working from a local copy, at minimum, even if you're not using Git to manage version history. The files in the directory you're working on contain the source representation of the metadata you're working on.
Probably not all of the metadata in the org, but you've surely got some of it if you've been working in VS Code. If you're using the Org Development Model, you will have a
package.xmlmanifest in your local project directory. That manifest will define which components you've retrieved, and likewise which components you'd be able to deploy into another org.You may need to expand your
package.xmlto include all of the ancillary metadata that's part of your whole application build, including any elements you may have created directly in the UI. Then you'd perform a retrieve in Visual Studio Code to pull all of those elements into your local source directory.Fundamentally, yes. Whether it will deploy cleanly or not is another question entirely - metadata often has many dependencies that are not completely obvious at first, on other metadata or on configuration of the target org. It's certainly worth trying in a sandbox and iterating until it works cleanly. The metadata entities you named all are relatively easy to deploy across orgs.