We've previously made deployments naively, that is deploying unpackaged metadata directly into a client org.

We'd like to start packaging things properly, either via unmanaged or managed packages.

My question is, what happens to the original objects in a client org when a package containing the same metadata is installed? Does Salesforce recognise that they are the same, or would it duplicate objects, tabs, pages etc.

So would I have to take the client's unpackaged data and reinsert it to target the managed package, and then erase the unpackaged metadata?


For unmanaged packages, any conflicts will either prevent the installation from occurring, or rename the incoming elements so they no longer conflict. This is generally a Bad Thing, especially if you're in the habit of using Strings instead of SObjectType and SObjectField tokens. You will end up with duplicates, assuming the install is allowed to succeed. Such packages are not upgradable, either.

So, if you're serious about servicing your clients, and especially if you want to allow them to upgrade to newer versions without conflicts/errors, you'll want to use a managed package. In that design, each package has a "namespace" that uniquely identifies the fields, objects, classes, triggers, layouts, and so on that are used in the package, preventing any possibility of conflicting with anything else a client may have manually created or installed from another package.

There are some limitations, such as what you can delete or modify, once the package is managed, but as long as you read the ISVForce guide beforehand, understand the implications, and abide by the rules, it should be entirely possible to remove many of the headaches that you have by using unmanaged packages. Also, managed packages obscure your code, protecting your intellectual property, and also allows you to turn off client licenses in the event that your app is no longer being paid for, etc (e.g. they can't steal your service that you were charging monthly/yearly for).

So, read the ISVForce guide, make your managed package, remember to pass a security review so you can get the Force.com Certified logo, and you'll be good to go (logo is optional, but highly recommended for your brand).

  • Thanks, my question was more around the issue of where clients data resides, and how I can migrate that "residency". Eg a naive object called "Site_Visit__c". The client has 2000 instances if this object. I then install my managed package which contains "MY_PACKAGE.Site_Visit__c". Is every Site_Visit__c instance now under MY_PACKAGE.Site_Visit__c? It seems unlikely. And I suspect I'll have to pull and push back using Jitterbit/Dataloader. I'll play around to find out, but this seems it should be documented to make clear. – powlo Feb 2 '15 at 10:31
  • You're correct. The elements without a namespace will be separate. That does imply you'll need to use some data ETL to move the data. This may or may not be trivial, depending on number of fields, etc. – sfdcfox Feb 2 '15 at 15:27

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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