function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion

Migrate whole SF instance - Best Approach?

Hi all,


I need to migrate a whole SF instance from a Sandbox to a Live system. There is code, VF pages, S-Controls, New Custom Objects, modifications on Standard Objects (added fields, modified fields, etc...).


I have a feeling that doing this via Eclipse will prove to be a bit of a challenge... Does anyone have a suggestion on how to do this with the least amount of headaches possible? Thanks,




I'm in the same boat.  There are limits to what the migration tool can do, and quite frankly, it's clunky.  I'm in the process of trying to obtain a tool call Snapshot from Dreamfactory.  It's on the app exchange.  It lets you take a snapshot of your sandbox, save that to a file, then push that file to another environment.  You can push the whole snapshot, push individual parts, compare two snapshots, etc... 


Seems like a good tool from the demos I've seen.


By the way, I don't work for snapshot.


Thanks, I do know Snapshot and was considering using it... But I was thinking about a free alternative. Regards,




You can create an unmanaged package in your Sandbox and move most of the migration that way. It's easy to create (all point and click), but it will not move the customizations on the standard object page layouts. In other words, the custom fields for Account will be there, but you will need to manually add them to the page layout. If this is a one-time move, I think this is a good approach.


Follow this guide to build your package. Remember, you must have 75% or more Apex Code test coverage.


Hope that helps,



Unmanaged packages can sometimes work, but to expand on Sati's point, only for new setup. If anything you're migrating already exists in the destination organization, the install won't work.  Most of the time when you develop in sandbox, you have in part been modifying stuff that was already in production. By contrast, Snapshot and the Migration Tool can update setup that is already present in the destination organization.


Snapshot vs Migration Tool .. they're intended for different things.  For folks looking for a graphical tool to help find changes and migrate them, Snapshot provides those things.  For folks looking for a scriptable tool supporting repeatable migration of a prestructured set of changes, the Migration Tool may be better.


Note that Snapshot and the Migration Tool migrate roughly the same kinds of setup information ... they both depend on a common underlying Metadata API to perform the migration.


One value of Snapshot, even if using the Migration Tool to deploy changes it supports, is that Snapshot can produce lists of other org setup differences, including setup types that are not supported by Metadata and which therefore can't be migrated automatically by either tool.  That can help if you need a list of changes to migrate by hand.