Information storage for online stores or uploading from 1C?

Question

1C

There is a client who has 5 i-no stores (1 RF, 2 UA, + one each in the prom / tiu catalogs), with the same goods everywhere (only 2 bases 1C - ukr + rus, 6,000 - 10,000 products each) . Made a long time ago and back off. All goods are unloaded from 1c, where they are also in a deplorable state (the main buyer is a wholesaler, so there is a minimum of information there - name + 1 photo + price) and, accordingly, what retail needs is not (beautiful descriptions, many photos, human names) .
And here the question arises of how to organize it so that all and-no stores give all the necessary information. Several paths have been considered:
1 Storage. A server that would receive the prices of goods from 1s, and store descriptions/photos/characteristics in itself, giving it to the rest of the guys via the API. Even without experience in the development of this, I will assume that it is enough to invest in this.
2 Organize 1C. Make a human filling of the goods in 1C, then distributing it where and to whom it is necessary. However, the client's 1C specialist said that storing tons of information in this system is very expensive, it is advisable to keep it clean, and put all the pictures / text / characteristics somewhere else (see point 1). Important! 2 BASES 1C THE CLIENT WANTS TO TURN INTO 1 (for two currencies) and, it seems, is moving towards this. Therefore, we will take for the initial data that the 1C base is one.
I myself am a front + solver of minor problems on these very sites. In any case, any of the options should be done by professionals (and not for 50 Belarusian rubles on my knee), but I'm interested in your opinion in favor of one or another option.
I tend to declension 1C to still give everything from it, and not make storage for a relatively small directory. But perhaps from there it is really so difficult to give everything away, as my friends tell me?

Answer 1

You cannot directly give data from 1C online on request
for two reasons:
1) this prohibits a license (more precisely, each such connection requires a license, not a site connection, but a site USER)
2) performance for web applications will not be very