Sounds like you need a join table between an estimate and customers, to show what customers have received the estimate. A wrinkle may be however that if one customer asks for a change and you don't want to affect the others.
Or one customer gets a different price tier than another...
In that case you may have to duplicate the estimate. But if then need to make a change that affects all "grouped" estimates...
It can get pretty complex so make sure you spend some time going over all possible scenarios before making an architecture decision.
As to converting an estimate to an order: definitely script it so that it becomes its own records. Orders can still change and you don't want it to affect the original estimate.
Before thinking too much about the HOW (whether to use popovers, scripts, portals, etc) I suggest you focus on, and get clear in your mind, the basic underlying data structure—what data you need to store, what tables you need to store it, what pieces of data go in which tables, what relationships you need to put in place to connect up the pieces. And of course all of that flows from writing down a clear, simple statement of the purpose of the database. e.g.:
This enterprise supplies xxx service/product to customers. Initially we put together estimates based on our understanding of what the customer requires. A successful estimate becomes an order, a completed order requires an invoice … etc etc blah and blah
Thanks for all of the suggestions they are all appreciated and I'll be implementing what I can shortly.