If it's the very worst case, the code is all scrampled, and all display is intermingled with the logic and the database calls, you might do what I had to do with one PHP project.
I gave it three starts on trying the refactoring approach. It was like hill-climbing on a motorcycle and getting 10% of the way each time. So I took another approach which ended up working out much better.
- I logged in as a user,
- and worked through every screen and every use-case I could find.
- I saved the html to static files,
- and took notes on the procedural operation and obvious business rules.
I did this for 3 solid days, and then took my notes and had a long conversation with the stakeholders.
After getting agreement on some first steps, I reimplemented all the html UI properly, using good consistent design and abstraction. After getting rolling, I could do a couple screens a day.
Then I took the result back to the stakeholders and ran through a bunch of use cases. (The stakeholders were immensely pleased at steps 1 and 2, because they didn't like the first implementation at all anyway (surprise) and now it looked like there was hope for improvement, not just recovery of sane-old-app.
That turned out to be the end of the hard work (and also the end of the perceived project risk for the stakeholders.)
It turned out that the first crew had gotten so tied up in their own misbegotten spaghetti that there was actually comparatively little content to the work, so duplicating it had less scope than everyone suspected.
But the key decision was that the original code, both content and structure, were unrefactorable and I needed to work from an entirely exterior view with a new framework that was properly designed.
