Database schema changes can almost always be moved forward in a always safe manner using expand-contract pattern <a href="http:&#x2F;&#x2F;martinfowler.com&#x2F;bliki&#x2F;ParallelChange.html" rel="nofollow">http:&#x2F;&#x2F;martinfowler.com&#x2F;bliki&#x2F;ParallelChange.html</a><p>As for reducing the risk of damage to the data itself from badly behaved application code, I think the best approach is to design your architecture such that you can&#x27;t lose important data.<p>There are various other techniques than can help. I wrote about some of them here <a href="http:&#x2F;&#x2F;benjiweber.co.uk&#x2F;blog&#x2F;2015&#x2F;03&#x2F;21&#x2F;minimising-the-risk-of-data-damage&#x2F;" rel="nofollow">http:&#x2F;&#x2F;benjiweber.co.uk&#x2F;blog&#x2F;2015&#x2F;03&#x2F;21&#x2F;minimising-the-risk-...</a><p>Releasing less frequently actually only makes the problem worse. Infrequent changes are often too big to have a chance of understanding their potential affect on the production system. You&#x27;re also less likely to immediately know how to respond to a problem.