We've now enabled the deployment of data to production orgs.

This feature needs to be explicitly enabled by the team owner via their account page. You cannot deploy data to orgs that you are not the owner of.

One very important things to note:
- There's no roll back functionality should a data deployment fail which means your production org data may be in a partial state that you don't want it to be in. We don't save any data so can't help you recover from any potential data loss.

We also highly advise you have a backup of your data before making any deployments to production.

You can find out more information via the blog post: https://gearset.com/blog/deploy-data-to-production-orgs

I totally agree about the need to push on production, when using Salesforce CPQ. And about the UI too.
And to me, the data deployment still lack some functionalities:
- restrain the migration to only one "experienced, seasoned" user by team
- documentation to explain the steps and the related data or objects involved
- roll-back (a tough one to implement, but so reassuring to have)

Other ideas:
- simulation (List of the actions and impacts on records and objects,on the production)
- only allow migration from cloning of a migration already done on a copy of the production
- validation by peer before the migration

Without the data rollback functionality, what would happen if data deployment to production failed (e.g. duplicate IDs)?

Given how sensitive user view their production data, would the non-reversible nature of data deployment make this feature undesirable?