We have a legacy order system and a new order system that are both currently active. The legacy order system takes 'offline' orders still, the new order system handles 'online' orders but uses the legacy order system for operations, so the legacy system has both offline and online orders. Eventually, the new system will handle all orders, but won't have historical orders in it.
I need a solution that can source order information from both systems and display in a single 'my orders' view for customers. There are a number of cases/rules where the source of the data depends on how the order was created, e.g. the delivery address will come from the legacy system if it was an offline order, but the new system if it was an online order, the billing entity will always come from the legacy system.
As we move functionality these rules will change, i.e. for certain types of offline orders, the delivery address needs to come from the new system regardless of origin.
In some cases, the data may not be in the legacy system, so will be blank, but populated in the new system, so we need defaults and/or fallback ("if not in legacy system, find in new system") behaviour for some data, e.g. products.
Is there a design pattern for this type of aggregation of two sources of data that would minimise future development required as we shift the 'source of truth'?