I'm trying to create a new instance of an existing Custom Object.

I have modified an existing object in the sandbox environment and want to preserve the original object when I push to production. Will it create a new version of this object if I have changed the name and API name of the modified object, or will it somehow see that this is the same object as the old and change it?

  • I believe a new object will create, as you changed the API name. To make sure, I suggest to create other sandbox and send changed object to there. So, you can see what will be the behavior
    – m Peixoto
    Commented May 24, 2019 at 13:14

3 Answers 3


Salesforce deployment works on the API name, so if the API name is changed in the sandbox environment and if you try to deploy that object, it will create a new object preserving the existing object in the production environment.

In case, you just changed the label and not API name, then it will overwrite the existing object in production with the new label name.

Same goes with all the other components.

  • Thanks for the quick answer! Do i have to worry about the field names and/or their API names? By my understanding there will be two objects with a lot of similar/identical fields when i push to production. I don't see why this would cause a problem. Commented May 24, 2019 at 11:58
  • Yes, if you are deploying the object with different API name, then having the field's API name same should not impact, as it will create two different independent objects which can have fields with same API names. Commented May 24, 2019 at 12:00
  • Perfect, thank you very much! Commented May 24, 2019 at 12:00

If the API name is the same, it will not detect that it is a different one when you deploy it to another environment.

If you have deleted fields from it, the fields will still exist in the target environment. If you have created new ones, they will be created. If you have created fields with the same API name, the platform will try to update the field type, but if it is a change like, say, picklist to checkbox, then the deployment will likely fail.

I think the content of these questions might help you:

Best practice in this case is, in my opinion, to just add a 2 at the end of your field's API name:

MyCustomObject__c would change to MyCustomObject2__c for example. The same for the fields. This should make it easier for you to migrate existing data, and definitely makes it easier to replace the fields in code. Since you won't be deleting the original field's data, you'll always be able to revert the changes in an easier way. And, of course, if everything goes smoothly after your new object/field is created and/or updated, it is also easier to just delete that old object/field.



If you edited the original object's API name, and you use a Change Set, it will cause the rename to occur in Production (the original object will be modified). Make sure you use a package or other deployment tool if you want to preserve the original object.

It would be safer to download the custom object, change its metadata file, and then redeploy to the Sandbox to make sure you have no association to the original object, and then you can safely use a Change Set to move those changes to production.

  • This goes against what other people told me. As i understand it, changing the API name and deploying will create a new object. Is this not the case? Commented May 25, 2019 at 12:16
  • @HansChristianMilman Unless the behavior has changed in the last few releases, Change Sets have always updated existing metadata even if you change the name. You can use a deployment tool, but not a Change Set.
    – sfdcfox
    Commented May 25, 2019 at 13:38

You must log in to answer this question.

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