2

What is the best and most comprehensive way of migrating all metadata, apex code, visualforce pages, sites, and everything else except records to a production environment from a developer account?

We've been building 'Salesforce 2' in a developer environment completely cut off from the production organization for the last few months and we're almost ready. But what is the best way to migrate EVERYTHING except records?

I've heard we should use the Force.com migration tool but does this copy everything including apex code or just fields and such?

Also please mark this question as a duplicate if it is, the only others I found like this were either only about migrating some parts or the questions had been removed from SFSE.

Improve this question
2
  • You're absolutely certain no design changes have been made in production during those few months you mention?
    – Jagular
    Jul 2, 2014 at 14:04
  • They haven't, but it doesn't matter if they have anyway. This new build has been signed off on and is just waiting to be deployed and then have the reformatted records bulk uploaded.
    – Adam
    Jul 2, 2014 at 14:07

2 Answers 2

Reset to default
5

I would recommend using the Force.com migration tool.

The best method I have found for retrieving metadata is not to manually construct a package.xml file, but to create an unmanaged package in your developer environment and then add all your componenets to this package.

You can then retrieve the entire set of components simply by referencing the package name:

<target name="retrievePkg">
    <sf:retrieve    username="${sf.username}" 
                    password="${sf.password}" 
                    serverurl="${sf.serverurl}" 
                    maxPoll="${sf.maxPoll}" 
                    retrieveTarget="${sf.retrieveFolder}" 
                    packageNames="MyPackageName"/>
</target>

and then validate & deploy to your production environment using the standard deployment process.

Let me know if you have any questions / issues with this method.

Improve this answer
3
  • What's the advantage of using an unmanaged package over a change set? Does this let you avoid having to add all the fields individually?
    – Jagular
    Jul 2, 2014 at 14:57
  • 3
    Change set is not possible in this scenario as Adam is trying to deploy from a dev. environment (not sandbox) to production, so there is no deployment connection between the environments.
    – Davin Casey
    Jul 2, 2014 at 14:58
  • I'll second the suggestion to use packages though there are a few things to be aware of. First, you are limited to only the metadata types which can be added to a package. For example, ActionOverrides on standard objects cannot be packaged. Second, as with any metadata based migration, be aware you will not get any custom setting configuration you made in your DE org as the data in custom settings is not metadata. Finally, when you deploy to your production org, you'll have to first create an unmanaged package with the same name in that org in order to use the retrieved package.xml.
    – Jason Lantz
    Jul 2, 2014 at 16:03
1

You could use the Eclipse IDE for this. One advantage to it is that you only need to select the object(s) to move, not all the individual fields. Of course, getting the Eclipse IDE set up can take time if you're not currently using it.

I haven't used the Force.com migration tool. Perhaps someone with experience of both will provide a comparison. I'd like to see that.

Improve this answer

You must log in to answer this question.

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