Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

How do I copy(for want of a better word) metadata (i.e. Objects, Workflows, Validation rule etc), and code (Apex, Visualforce, Triggers) from one Production org to another production org?

Is this even possible? I know that Change Sets won't help here since they work only within an org.


share|improve this question
To help those that come after: This question refers to a one-time deploy if you read through all of the answers below. – Akrikos Apr 23 '13 at 21:46
up vote 29 down vote accepted

You can use the IDE to do this. Follow the download and installation instructions here: IDE Installation

Once the IDE is installed, create a new project and provide the source org's login information and choose all meta-data objects you want to deploy to another org. Once they've all be downloaded into your project, right-click on the project and select ">Deploy to Server" and the tool will walk you through the process with a wizard.

share|improve this answer
Thanks @E.J.Wilburn ! I have used IDE to deploy changes from a sandbox to a prod org. But I have never used it deploy code and metadata from one prod org to another. Lets say I have the eclipse project connected to Prod Org 1, can I then just deploy it to Prod Org 2 using the deploy wizard? – Anup Aug 1 '12 at 7:32
Hi @Anup yes you can deploy the metadata and code in that way. The wizard asks for the login details of the target org. It doesn't have to be the same as the one linked to the project. – Born2BeMild Aug 1 '12 at 7:48
Yes. It will work as it does when deploying from sandbox to production. You won't be able to edit any of the components you can't edit via the web UI though, they'll be in read-only mode and saving any changes will result in an error. – E.J. Wilburn Aug 1 '12 at 7:54
note, if you have selected Profiles in the source project that makes deployment VERY hard because those Profile settings even if you don't select the Profiles to be deployed carry over. e.g. you have a field on a Account that is FLS private for all except a Profile *CustomAdmin...when you try to deploy that custom field it will fail because the destination org doesn't have *CustomAdmin profile. My suggestion - have your project just be config/code/report, etc minus profiles, then in your destination org re-do security as you see fit, or bring over the Profiles too which is harder, but doable. – caleb Aug 1 '12 at 15:01
You're talking about managed fields/objects from a managed package and no those can't be copied via any means. You have to have the managed package installed in both orgs. If it's a production org with the package installed it will automatically be installed in any sandbox when that sandbox is refreshed. Otherwise you'll need to install the package in both orgs. – E.J. Wilburn Oct 26 '15 at 5:09

You can also use the Ant based Migration Tool:

share|improve this answer
If you are doing the same deployment over and over, I would recommend the migration tool as well. If it is a small number of different files each time, going through the IDE would probably be easier than setting up and modifying the migration tool configuration. – Rob Scott Aug 1 '12 at 20:15
Thanks! This is a one-off migration/cloning process to create a new org using another org as a template. – Anup Aug 2 '12 at 5:51
Even one-off migrations typically involve repeating the deployment several times due to errors during the deployment. Also, the migration tool is typically significantly faster than the IDE. That said, use the IDE's GUI to create your package.xml file, that will save you some time and hassle. – Mike Ginou Jun 20 '13 at 15:29

I should point out that the following items cannot be deployed through Eclipse (at least from what I can find):

  • Approval Workflows (Available as of Summer '13)
  • Chatter Settings
  • UI Settings
  • Lead Settings
  • Email Settings
  • Organization Settings
  • Outlook Configurations
  • Offline Configurations
  • Mobile Configurations
  • Lead Assignment Rules
  • Case Assignment Rules
  • Custom Object Criteria Based Sharing Rules
  • Content
  • Knowledge
  • Ideas
  • Queues (not positive on this since I know Groups can be deployed now)
  • Time-Dependent Actions (the rules can be deployed, but the time-dependent part needs to be re-created)
  • Email Services
  • Scheduled ApexJobs/Reports/Dashboards
  • OrgWide Email Addresses
  • Renamed Fields/Objects
  • Individual Users Email Signatures, Chatter Settings, Outlook Configuration, Offline Settings, Personal Groups, Update Reminder Settings
  • All Reports, Dashboards or Email Templates that are in a users "My Personal Reports" or "My Personal Templates" folder
  • All Private List Views
  • Anything considered "Data" (with the exception of Documents, which for some reason can be deployed through Eclipse).
share|improve this answer
The full list is here:…. Note that Change Sets actually support less: – Peter Knolle Aug 21 '12 at 9:56
This answer doesn't help except as an addendum to the accepted answer. I'd rather see you also recommend eclipse and then give a caveat or something. I'd upvote that. – Akrikos Apr 23 '13 at 21:45

Another mechanism is to create an unmanaged package. The list of package-able components (from the relevant page in the ISVforce Guide):

  • Analytic Snapshot
  • Apex Class
  • Apex Sharing Reason
  • Apex Sharing Recalculation
  • Apex Trigger
  • Application
  • Article Type
  • Custom Button or Link
  • Custom Field
  • Custom Label
  • Custom Object
  • Custom Report Type
  • Custom Setting
  • Dashboard
  • Document
  • Email Template
  • Field Set
  • Folder
  • Home Page Component
  • Home Page Layout
  • Letterhead
  • List View
  • Page Layout
  • Permission Set
  • Record Type
  • Remote Site Setting
  • Report
  • S-Control
  • Static Resource
  • Tab
  • Translation
  • Validation Rule
  • Visualforce Component
  • Visualforce Page
  • Workflow Email Alert
  • Workflow Field Update
  • Workflow Outbound Message
  • Workflow Rule
  • Workflow Task
share|improve this answer
Note that this don't work very well for copying profiles. The profiles you package aren't full profiles but really "fragments" of them that get merged with the existing profiles in the org you're installing into. Be prepared to re-configure page layouts, FLS, and others when doing this. Especially for the admin profile as you can't even apply a profile "fragment" to it during install for some seemingly arbitrary reason. – ca_peterson Aug 1 '12 at 19:56
Good observations. Thanks, @ca_peterson! – metadaddy Aug 1 '12 at 19:57
This is interesting! I'll definitely check it out. – Anup Aug 2 '12 at 5:51
The profile "fragment" issue is true of ALL deployment methods (including IDE, ANT, and managed packages). – Mike Ginou Jun 20 '13 at 15:34
Unmanaged packages should really be avoided. The packaging mechanism does have a handy feature to automatically pull in dependencies (unlike building a changeset). However, the inability to update a managed package can really be annoying down the road. One handy trick that I have used in the past is to build an unmanaged package, create a new project based on that package, then use the resulting package.xml file with the ANT migration toolkit. That's a bit convoluted, but you do get the handy dependency bit, plus repeatable deployments. – Mike Ginou Jun 20 '13 at 15:37

What about the DOT process? Especially for a 1-off copy. This refers to the option of creating (or having SFDC create) a 'DOT' template - this can include or exclude data, and obviously includes the full org meta-data.

We use this process at Veeva - for large deployments across multi countries, we often end up with several 'child' production orgs, cloned from a master org. We use the DOT process for this - no IDE/API calls required, and from the end admin perspective it's generally just down to creating the DOT template, then logging a SFDC case to use this to create a new production org.

Not sure if this is generally available to the whole SFDC community, we are an ISV/OEM partner so might get this through that agreement, but thought I would put this as another option - again, for 1-offs it is a lot simpler than using API/IDE/other tools. Has anyone else used this/seen it used? If not then I'll remove this, but wanted to throw it out there...

share|improve this answer
What does DOT stand for? – codeulike Aug 6 '15 at 10:54

SnapShot ( can migrate from any Org to any Org (as long as you have admin credentials). This includes migrating profiles, partial profiles - only FLS of one field but not the other etc., objects, workflows etc. You can even edit the profiles to update security settings en masse before migrating it to the destination.

This is a paid app on AppExchange.

Disclaimer: I work for DreamFactory, the makers of SnapShot.

share|improve this answer
Why the down vote? – JannieT Sep 26 '13 at 10:52

Another way I suppose would be to, instead of using ANT, use Workbench with a .zip file containing xml files. More info on this can be found on the answer by sfdcfox here.

Finally, another way to achieve this with MavensMate and Sublime Text 3 (i.e. without having to use IDE) can be found here.

share|improve this answer

protected by Jesse Altman Oct 9 '13 at 18:42

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.