I'd like to build on what ChrisF and Morons have already said.

From ChrisF's answer:

If you want to rewrite the application then you don't need to know how it does what it does but you do need to know what it does.

I agree 100%.

From Morons's answer:

Ask users about System integration, basically anything that may be happening behind the screen that is not reflected in the UI or with a Db interaction. (Sending and Email. FTPing something, whatever)

Ask About anything the runs on a schedule. Look at all the SQL behind the major reports in the System.

Agreed. Great point about the scheduled jobs.

Document, Document, Document.. Then Finally, once you got all the info you can this way. Start looking at the code for areas where you need clarification.

Right.

Test every Field for data validation.

OK.

Then you need to go though all the screens and use cases while running an DB profile. Document All the Db transactions on each screen.

I disagree.

• Exhaustively profiling the database is not a good use of your time.
• It could also be misleading.
• Emphasis: As ChrisF said, focus on what the application does, not how it does it.

Also, know that: You will make mistakes! :)

Of course, as the technical lead, it's your responsibility to minimize these mistakes to the extent that the new system mimics the core functionality of the old system.

Having said that...

• It seems like this will be a worthwhile effort because you're making the system maintainable and you're erasing a large amount of technical debt.
• I just don't think it's useful, productive, efficient, or even fiscally responsible to burden yourself with a overly perfectionist attitude on this job.

I'd like to build on what ChrisF and Morons have already said.

From ChrisF's answer:

If you want to rewrite the application then you don't need to know how it does what it does but you do need to know what it does.

I agree 100%.

From Morons's answer:

Ask users about System integration, basically anything that may be happening behind the screen that is not reflected in the UI or with a Db interaction. (Sending and Email. FTPing something, whatever)

Ask About anything the runs on a schedule. Look at all the SQL behind the major reports in the System.

Agreed. Great point about the scheduled jobs.

Document, Document, Document.. Then Finally, once you got all the info you can this way. Start looking at the code for areas where you need clarification.

Right.

Test every Field for data validation.

OK.

Then you need to go though all the screens and use cases while running an DB profile. Document All the Db transactions on each screen.

I disagree.

• Exhaustively profiling the database is not a good use of your time.
• It could also be misleading.
• Emphasis: As ChrisF said, focus on what the application does, not how it does it.

Also, know that: You will make mistakes! :)

Of course, as the technical lead, it's your responsibility to minimize these mistakes to the extent that the new system mimics the core functionality of the old system.

Having said that...

• It seems like this will be a worthwhile effort because you're making the system maintainable and you're erasing a large amount of technical debt.
• I just don't think it's useful, productive, efficient, or even fiscally responsible to burden yourself with a overly perfectionist attitude on this job.

I'd like to build on what @ChrisF and @Morons have already said.

From @ChrisF:

If you want to rewrite the application then you don't need to know how it does what it does but you do need to know what it does.

I agree 100%.

From @Morons:

Ask users about System integration, basically anything that may be happening behind the screen that is not reflected in the UI or with a Db interaction. (Sending and Email. FTPing something, whatever)

Ask About anything the runs on a schedule. Look at all the SQL behind the major reports in the System.

Agreed. Great point about the scheduled jobs.

Document, Document, Document.. Then Finally, once you got all the info you can this way. Start looking at the code for areas where you need clarification.

Right.

Test every Field for data validation.

OK.

Then you need to go though all the screens and use cases while running an DB profile. Document All the Db transactions on each screen.

I disagree.

• Exhaustively profiling the database is not a good use of your time.
• It could also be misleading.
• Emphasis: As @ChrisF said, focus on what the application does, not how it does it.

Also, know that: You will make mistakes! :)

Of course, as the technical lead, it's your responsibility to minimize these mistakes to the extent that the new system mimics the core functionality of the old system.

Having said that...

• It seems like this will be a worthwhile effort because you're making the system maintainable and you're erasing a large amount of technical debt.
• I just don't think it's useful, productive, efficient, or even fiscally responsible to burden yourself with a overly perfectionist attitude on this job.

I'd like to build on what ChrisF and Morons have already said.

From ChrisF's answer:

If you want to rewrite the application then you don't need to know how it does what it does but you do need to know what it does.

I agree 100%.

From Morons's answer:

Ask users about System integration, basically anything that may be happening behind the screen that is not reflected in the UI or with a Db interaction. (Sending and Email. FTPing something, whatever)

Ask About anything the runs on a schedule. Look at all the SQL behind the major reports in the System.

Agreed. Great point about the scheduled jobs.

Document, Document, Document.. Then Finally, once you got all the info you can this way. Start looking at the code for areas where you need clarification.

Right.

Test every Field for data validation.

OK.

Then you need to go though all the screens and use cases while running an DB profile. Document All the Db transactions on each screen.

I disagree.

• Exhaustively profiling the database is not a good use of your time.
• It could also be misleading.
• Emphasis: As ChrisF said, focus on what the application does, not how it does it.

Also, know that: You will make mistakes! :)

Of course, as the technical lead, it's your responsibility to minimize these mistakes to the extent that the new system mimics the core functionality of the old system.

Having said that...

• It seems like this will be a worthwhile effort because you're making the system maintainable and you're erasing a large amount of technical debt.
• I just don't think it's useful, productive, efficient, or even fiscally responsible to burden yourself with a overly perfectionist attitude on this job.