1. carefully map out the table structures and relationships of the pick application. then "re-map" these table structures and designs to a non mv data model (read: sql relational model). you need a good understanding of pick to do this.
   
   
2. simply write out the requirements of the original system, and use those requirements as the master design document. (i.e.: don't use the tables as a design document at all. write a new specification from scratch)
   

#1 size=4>with a good data design, >
in addition, the work in option #1 is required if data is to be transferred from the old system to the new. hence if relational data is to be transferred from pick, then the structures of existing data needs to be known. i emphasized the word relational here. it is not needs to be known. i emphasized the word relational here. it is not a big deal to transfer a client file. however, if we are to transfer a client file *and* past "invoices" (with detail), then we have re-structuring and re-formation of our data model. this can be quite bit of work. one has to ask how important is the need is to transfer data, and how "relational"  is that data. the more relational the data, the more work required to transfer.