36

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.

Thanks!

Improve this question
1
  • 1
    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, 2013 at 21:46

7 Answers 7

Reset to default
33

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

Once the Force.com 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 "Force.com->Deploy to Server" and the tool will walk you through the process with a wizard.

Improve this answer
9
  • Thanks @E.J.Wilburn ! I have used Force.com 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, 2012 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, 2012 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, 2012 at 7:54
  • 4
    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, 2012 at 15:01
  • 1
    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, 2015 at 5:09
16

You can also use the Ant based Force.com Migration Tool:

http://www.salesforce.com/us/developer/docs/apexcode/Content/apex_deploying_ant.htm

Improve this answer
3
  • 3
    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, 2012 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, 2012 at 5:51
  • 1
    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 Force.com IDE. That said, use the Force.com IDE's GUI to create your package.xml file, that will save you some time and hassle.
    – Mike Ginou
    Jun 20, 2013 at 15:29
15

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).
Improve this answer
2
8

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
Improve this answer
4
  • 3
    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, 2012 at 19:56
  • This is interesting! I'll definitely check it out.
    – Anup
    Aug 2, 2012 at 5:51
  • 1
    The profile "fragment" issue is true of ALL deployment methods (including Force.com IDE, ANT, and managed packages).
    – Mike Ginou
    Jun 20, 2013 at 15:34
  • 1
    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 Force.com 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, 2013 at 15:37
5

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...

Improve this answer
3
  • What does DOT stand for?
    – codeulike
    Aug 6, 2015 at 10:54
  • DOT = Default organization template. Essentially a template starting point for a new org, which can be created based on the DOT of another org rather than as a net-new Salesforce org.
    – Stephen B
    Jul 4, 2016 at 11:35
  • Ah I see. it looks like DOT is only for ISVs.
    – codeulike
    Jul 4, 2016 at 11:55
4

SnapShot (http://appexchange.salesforce.com/listingDetail?listingId=a0N300000016YhyEAE) 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.

Improve this answer
1
  • Why the down vote?
    – JannieT
    Sep 26, 2013 at 10:52
0

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 Force.com IDE) can be found here.

Improve this answer

You must log in to answer this question.

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