This is a case where having a defined development process and good sharp tools can be very helpful. Here are the steps I'd use to tackle this problem code (though it's based on what you wrote above and might need to be adapted as you learn more.
1) Study how the software is actually used and design the "ideal architecture" (this may be a moving target).
2) Get the software into a version control system.
3) When a section of the code needs work, first write tests that pass for the current functionality of the module but fail for the behavior you're trying to fix.
4) As you repair code in step 3, also migrate the code "towards" your preferred architecture ... this is going to be a very gradual process so don't try to complete it in one step and use your tests to verify you haven't broken the system. This is also a good time to start inserting patterns like MVC/MVP as it will help. - http://c2.com/cgi/wiki?TestEveryRefactoring
5) When you've found "reams of copy+paste code", refactor that code into utility classes (files, whatever). - http://martinfowler.com/refactoring/
6) Establish processes for migrating the database both forwards and backwards between versions (you'll need a rollback someday).
7) Treat the database schema as source code and refactor it as you work. It sounds like you're a long way from being able to use an ORM, but have a plan for migrating the database towards the day you can. - http://martinfowler.com/articles/evodb.html
8) Get the PHP code out of the database ... that's going to be painful but worthwhile.
9) Get some help! I've used the Sonar source code quality analysis tools on Java projects for years. There's a PHP plugin for it here (http://docs.codehaus.org/display/SONAR/PHP+Plugin) and it will help you determine what areas might be worth targeting. It also helps by establishing style and practice rules that will help get a team coordinated.
One of the hallmarks of a project like this is that coding styles changed dramatically during the project's existence - Establishing a style guide (including patterns and forbidding anti-patterns) can be very helpful.
So in short ... don't "run screaming" but rather sit and think when you feel overwhelmed. If you can solve a complex problem when writing source code, you can also solve systemic problems.
Comments
This is a case where having a defined development process and good sharp tools can be very helpful. Here are the steps I'd use to tackle this problem code (though it's based on what you wrote above and might need to be adapted as you learn more.
1) Study how the software is actually used and design the "ideal architecture" (this may be a moving target).
2) Get the software into a version control system.
3) When a section of the code needs work, first write tests that pass for the current functionality of the module but fail for the behavior you're trying to fix.
4) As you repair code in step 3, also migrate the code "towards" your preferred architecture ... this is going to be a very gradual process so don't try to complete it in one step and use your tests to verify you haven't broken the system. This is also a good time to start inserting patterns like MVC/MVP as it will help. - http://c2.com/cgi/wiki?TestEveryRefactoring
5) When you've found "reams of copy+paste code", refactor that code into utility classes (files, whatever). - http://martinfowler.com/refactoring/
6) Establish processes for migrating the database both forwards and backwards between versions (you'll need a rollback someday).
7) Treat the database schema as source code and refactor it as you work. It sounds like you're a long way from being able to use an ORM, but have a plan for migrating the database towards the day you can. - http://martinfowler.com/articles/evodb.html
8) Get the PHP code out of the database ... that's going to be painful but worthwhile.
9) Get some help! I've used the Sonar source code quality analysis tools on Java projects for years. There's a PHP plugin for it here (http://docs.codehaus.org/display/SONAR/PHP+Plugin) and it will help you determine what areas might be worth targeting. It also helps by establishing style and practice rules that will help get a team coordinated.
One of the hallmarks of a project like this is that coding styles changed dramatically during the project's existence - Establishing a style guide (including patterns and forbidding anti-patterns) can be very helpful.
So in short ... don't "run screaming" but rather sit and think when you feel overwhelmed. If you can solve a complex problem when writing source code, you can also solve systemic problems.
Good luck!