You know what sounds like a bad idea to me? Probably not, so let me give you an example:
Having the [legacy product] code to refer to is crucial to the database design work we’ll be doing on the new project.
It’s a bit like saying “Hey guys, obviously the old software isn’t meeting our needs, but let’s base our new, replacement idea on the old code”. That’s not going to be easy to do. In fact, I’d venture to say that the smarter, clearer way to go would be to take a good look at your current requirements, go over your use cases, and “user stories”, and start from scratch.
I’m willing to be 90% wrong here, in general cases, except for where my vagueness and ambiguity hides the real-life project to which I have direct knowledge.
Moving away from the technological view, and into your life -
Are you trying to compare your past to the present, in order to build the future?
Forgetting the past and taking a good inventory of the resources you currently have available is going to be the most stress-free way to move forward.
Of course you need to examine history to learn from your mistakes, and observe the way others have done things correctly. But when it’s time to move on to something new, it’s hardly ever good to use old material to build something new.
Old wine-skins, new patches, and all that.