Make sure the code (including any stored procedures or code that is otherwise stored in the database) is in a version control repository. Because any change in this code might have unexpected, subtle consequences (i.e. introduce more bugs). In which case you'd do better rolling back that particular change.
The next step would be to get a grip on deployment. Automate it, so you can roll out updates and roll back updates to all clients without breaking a sweat.
Then set up a proper backlog and bug tracking system, where you can prioritize bugs and work items. (And maybe open it up for bug reports by clients?)
Just like with a real debt, with a technical debt, seeing progress can help to keep you going. At this point, you should have a grip on it, it's just still going to be a lot of hard work. There's good advice on how to approach the refactoring.
Finally, and this is not related to the code, educate stakeholders in your organization about the concept of technical debt. (Back it up by time tracking various work items from the bug tracker.) Somehow your organization got into this situation, so there may be a problem where new features or custom features for clients get priority before bugfixes, and are written without much guidance. Joel Spolsky has written on this subject, you may find his writings help explain the concept, as well as find a way out of this mess (like the '12 steps to better software').
Comments
Make sure the code (including any stored procedures or code that is otherwise stored in the database) is in a version control repository. Because any change in this code might have unexpected, subtle consequences (i.e. introduce more bugs). In which case you'd do better rolling back that particular change.
The next step would be to get a grip on deployment. Automate it, so you can roll out updates and roll back updates to all clients without breaking a sweat.
Then set up a proper backlog and bug tracking system, where you can prioritize bugs and work items. (And maybe open it up for bug reports by clients?)
Just like with a real debt, with a technical debt, seeing progress can help to keep you going. At this point, you should have a grip on it, it's just still going to be a lot of hard work. There's good advice on how to approach the refactoring.
Finally, and this is not related to the code, educate stakeholders in your organization about the concept of technical debt. (Back it up by time tracking various work items from the bug tracker.) Somehow your organization got into this situation, so there may be a problem where new features or custom features for clients get priority before bugfixes, and are written without much guidance. Joel Spolsky has written on this subject, you may find his writings help explain the concept, as well as find a way out of this mess (like the '12 steps to better software').
Good luck!