Apex Code Development You need to sign in to do that
Don't have an account?
Lawrence-CEC Checklist for copying an org?
Does anyone have a checklist of all the things you need to look for when copying an org to a new instance?
We are in the process of copying an existing org to a new org and unfortunately SFDC doesn't have a simple "copy org" function that goes from production org to production org like it does from production to sandbox. So we are having to do it manually, but we are finding that doing so is a *huge* mess as only certain things are available through the force.com IDE and exactly where you need to go to copy over a certain bit of functionality is not always obvious. (For example: field level security doesn't appear to come over and must be reconfigured manually; picklist values on custom objects and custom fields on standard objects *do* come over through the IDE, but custom values on standard fields for standard objects *do not*.)
So, does anyone have a checklist for all the things you need to account for during a migration like this? I.e. objects, triggers, email templates, customized picklist values, personal reports, etc. An indication of what can be copied over via the force.com IDE, the data loader, and what needs to be done manually would be a huge help too.
We think we have most of the items covered, but want to make sure we aren't missing some small bit that's important.
Thanks,
---Lawrence
The Force.com IDE still has a few gotchas. I recommend that you try out the Ant Metadata Tool instead. I very recently posted about migrating all the metadata for an org: http://boards.developerforce.com/t5/New-to-Cloud-Development/Saving-Dreamforce-Hand-on-Lab-work/m-p/229107#M1245. That being said, you may want to tweak the package.xml file to suit your needs.
As you've noted, standard objects do not copy over their settings by default. To do this, you have to explicitly name them in the package.xml file (as in my post). Also, Field Level Security is copied only if you copy Profiles as well. Copying the objects only copies the fields and defaults their security, while the Profile determines their Field Level Security settings.
I would use the Metadata API documentation to generate a complete checklist. Note that some items, like Email Templates, have to be moved through the Apex Data Loader, which means mapping ID values from one org to the other.
Great, thanks sfdcfox. That looks helpful. I take it the package.xml you list in your earlier post will need to be tweaked to fit our particular instance. I tried running it and got a lot of errors.
I've actually been trying to break it down into some simple tests to try to help me understand the tool. And I've run into what may be a basic problem, but I'm having difficulty figuring out how to do what is needed.... I've updated your package.xml to remove all except the Product2 custom type and when I run it, I get an error saying "In field: groups - no Group named Sales Operations found"... Which makes sense since that group doesn't exist yet in the new org. But I can't figure out how to load the group definitions.
I tried adding a new <member>Group</member> in the CustomObject type block, but that gives me an error of "Can't retrieve non-customizable CustomObject named: Group".
I've searched what documentation I've been able to find and I wasn't able to find something that said "to retrieve a Group... do this". I see the list of <name> values, but I'm not sure where under that I get a list of <member> values... and I'm not even sure that I'd find "Groups" under that list.
Any suggestions on where to go from here? Is there a list somewhere that shows me how to pull down specific elements? (I.e. that "to retrieve all Groups ... do this") Is there some way to pull down a master list of *all* metadata components so that I can essentially pick and choose the pieces that I want and/or are needed?
Thanks,
---Lawrence
Let me ask another question that may help clear up my confusion...
I've thrown out the idea that migrating an org was a simple one-step process that SFDC had already implemented. From what I've had explained to me, I'm now under the impression that it's really a two step process (two main steps, each with a ton of sub-steps):
1) Load all the metadata describing all objects and 'non data'
2) Load all the data
Is this correct? Or does the process really involve going back and forth moving over bits of metadata, then bits of data, then more metadata, then more data, etc.
The reason I ask is that you said that Email Templates have to be loaded through the data loader. But I believe triggers are dependent on Email Templates (because triggers use the templates to send out notices?). So if triggers are loaded via the metadata API, but Email Templates are loaded via the data loader, but you'd first need to load the Email Templates metadata, ... it is looking more and more like this is a convoluted process of going back and forth...
-L
Relational Junction has exactly what you're looking for. The original org is replicated to a sql database (Oracle, SQL Server, MySQL, etc.). Records are then selectively marked for insertion to Salesforce, and updated with any metadata changes needed, such as new RecordTypeID's. Parent-child relationships are maintained by database triggers, making it a one-pass process to replicate the staging database to Salesforce. We've done many projects like this in about 40 man-hours.
Contact me directly for more information.
Rick does make a good point that there's already software out there that can do this for a nominal price. However, if you're still trying to take a go at it, I suppose you'd really need about five steps to achieve 100% replication:
1) Copy all non-setup object metadata (Account, Contact, etc.)
2) Copy all setup customizable object metadata (User, etc.)
3) Copy all setup non-customizable object data (EmailTemplate, etc.)
4) Copy all setup non-customizable object metadata (Workflow, etc.)
5) Copy all development metadata (ApexClass, ApexTrigger, etc.)
5) Copy all non-setup object data (records)
You have to resolve things in order of dependencies, and it seems to me that this is probably nearly the correct order. You'll probably just want to go with a solution that's already built to save yourself the headache...