I created an app with much the same data architecture behind it; we have an onsite SQL database containing most of the automation and internal day-to-day information, and then a third-party cloud service used for sales, account management, field personnel, etc. Helpdesk needed information from both regarding clients' physical locations and equipment, and had been getting it from two different applications until I stepped in.
The long and short is that one data source needs to have a reference to the records of the other. In our case, the third-party cloud data contains references to the onsite data because that's the arrangement we had the most control over. Now, with an ID for a record from either data source, we can get data from both; with a cloud ID, we pull the record from the cloud, get the onsite ID, and pull the onsite data. With an onsite ID, we poll both data sources based on that ID.
In my system, I didn't make either object a child of the other in the domain layer; any usage of the data from both of the stores must maintain two object instances. Neither one is guaranteed to exist, which is why I did it that way; the app can work only with cloud data, or with onsite data, or both, with more limitations the less data it has.
However, that's not difficult to change, especially if you are sure that one side will always exist; simply include a property in the object representing the side for which data will always exist, that is of the object type representing the other data store's record. More advanced "merging" of the two graphs into one is possible.
This sort of arrangement must necessarily be coupled at some level. You can have a DAL that can interface with both data stores, or you can segment the DALs, one per data store, and have a higher layer such as a Controller get the data from each and snap them together. But, at some level, your program has to have the smarts to put these two disparate data sources' data together.
You can reduce the coupling required in most cases by abstracting away details of exactly where the data comes from. If you get data from a web service, which is given to you as instances of generated classes, then put a converter in place to make a deep copy of the service class into something you control, which won't have to change if the data source does (only if the schema does).
Now, this can be a huge undertaking; the cloud we use has dozens of domain classes, some of which have hundreds of data fields, and - here's the kicker - you could very easily have to make large changes to the abstract data type to accommodate a move to a different cloud or other remote data source. For that reason, I didn't bother; I use the generated web service domain directly, and now that a change from the cloud to an offsite (but under our control) data store is looming, the details of which I still do not know, I am simply planning to change the forms and codebehinds of the app, which is where the data is "combined", to reflect the new schema and/or data objects. It's a big job whichever way you slice it.