Best practice for unwanted objects

Deleting objects is not recommended I guess. I would add the description as deprecated and Update the name of the object with DEP_objectName etc and then remove/erase the code from the objects and deploy it to higher environments.

I would simply mark them as deprecated (with a DEPRECATED prefix). Move them to an application with all your other deprecated objects. Push that app across your environments.

You can choose to delete them manually at some point if you wish.

Echoing the others slightly, my procedure (personally) is something like:

1) mark as "deprecated" in the description, including the rule/interface name that designers should use instead (if any)
2) procedurally remove the deprecated object from in-use objects, either slowly or quickly depending on the urgency
3) only after it's been removed from all dependents, rename with "DEP_" or "DEPRECATED_" prefix (per your preference), and MOVE TO A FOLDER dedicated to deprecated objects
  note: i usually use the prefix "zDEP_" or similar, so the deprecated objects don't show up on the auto-complete picker higher than the actual objects i'm searcing for.
4) deploy any newly-deprecated objects to higher environments
5) optionally, you can delete fully-deprecated objects - I almost always take a BACKUP EXPORT first (perhaps from a separate app named "deleted objects backup export" or thereabouts), for the 'archives'.  I would do this for one object at a time (or a small handfull if they're related somehow and have all been fully deprecated).  Then they can be individually deleted (directly from the individual environments), making sure to match them object-per-object.  For safety reasons it might be good to deploy the current contents of the "deleted items" app package to the target environments first, so that it would populate the exact items to delete, to avoid accidental deletions of similar-named objects etc.

Note: I often don't bother proceeding to step 5 - there's very little risk in allowing deprecated objects to sit around.

Thanks Kondaru.

Is there a reason why the object deletion should be avoided ? Specially when we are sure that it does not have any dependents(not being used)

Thanks Mathieu.

Same question , is there a reason why the object deletion should be avoided ? Specially when we are sure that it does not have any dependents(not being used).

Also maintaining and deploying such a deprecated objects app each time could be an overhead. Specially when we have a single shared app across all the other apps.

There is no compulsion that you should not delete the objects on any environments. Its just that you need to make sure that there is no dependencies on those objects that you are planning to remove. When it comes to Higher environments the usual developer who makes the developments in dev would not have access to Prod (In most cases), there would be separate teams to handle the things in the Prod. So to avoid any mishaps in case the person deleting the objects has low level of awareness of the dependencies. Some applications might use the UUIDs stored in database to trigger processes or any sort of action related to the objects, this would break if no proper handling is done and the rule or logic is looking for that UUID object. For instance lets say there are few API which have no dependencies in the application but the object is being used by some third party, this will also break. Any of this will be avoided if the objects were initially marked as DEP or moved into a separate folder.