Step 1 is that you must come from a mindset that this (the update breaks other stuff) is not normal. Your update should not break or slow other parts of the app. It's not ok, it's not to be expected, and it's not the user's fault when they complain about it. You should be doing as much testing as you can to try to prevent it. When it happens you have a problem, and an urgent one.
Step 2 is that you must know what you did. Your source control system might be able to help you, or some kind of work tracking system, but you must be able to say the minute you get one of these complaints "ok, I added a column to this table, changed this grid to calculate the new taxes, added those two new reports ..." and so on.
Step 3 is that you must have experience finding perf issues and crashes quickly, so you know what sorts of things are likely to cause them, and can get to the problem right away. This thing has gone live and you must find the problem quickly and get a patch out. Changing a report can't slow down a part of the app that doesn't use the report. You are in emergency mode now and have to figure out where the mistake is and what to do about it - without breaking another part of the app in the process.
Step 4 is for each one of these miseries, you should learn a lesson that you will test for next time. You will become "that guy" who objects to certain constructs because "that will be horrible when there are 10,000 records".
A little more on the "this is normal" front. I run (among all the other things we have going on) an agile project for an external customer. We've been doing releases roughly every 6 weeks for two or three years now. And yes, the release is scheduled to the minute. We just did one at 8am yesterday. And roughly every 4th or 5th release (once or twice a year, in other words) something gets broken live, and we leap into action and make it right as quick as we can. Even though we test and test and test before the release. Then we tell them what happened. "There was a little bug in the June deploy that let this field be blank, but we never noticed because we weren't using the value at that time. Then in this deploy when we started using the field, the ones that were blank caused that error message you saw. We've fixed the bug so they can't be blank, put values in the bad records, and confirmed that it doesn't blow up any more. Our apologies." Or "That emergency change you begged for, just two days before the release, had consequences we didn't think of and didn't test for. Remember why we resist emergency changes?" I may not be a bad programmer for making it worse with the update, but I surely did do a bad thing. And I need to make it right.