I would think you'd want the customer data to remain updated in **any** case - so any references to "customer" would display the current info - pending the below conditions.
For work orders, this is fairly easy - you should always store work order/invoice info with the actual values in a table of their own, and not join those values on the products table. It may be wise to collect the customer info at that point and store them in this table too.
Take an ecommerce example. Your customer comes to the site, enters their info, purchases a widget for a price. When the order is complete, you store their email, address, and actual widget price in the completed orders table. When they change their email or address, it updates the customer table, but not this one.
For orders in progress, you may use that scheme and have an extra tinyint field containing a value representing in progress or complete. When the order is opened, you store the current widget price. Next day, you raise the price which only affects the products table, not this order.
Given that scenario, I'd still refer to the customer table for customer info - unless you have the ability to enter multiple addresses, as in, different shipping locations. Then you'd have to devise a way to assign which address is for this order - a drop down list, for example.