This is an interesting issue and one that has come up a lot in the Canadian context, where each province/territory has a portal site (most of which now use AtoM), and each portal sends its data to the national archival portal (also running AtoM). This particular use case was unfortunately not considered during the original application design 10 years ago - and the technology landscape has changed a lot since then. We hope to be able to incorporate a solution for this directly into AtoM3 in the future, but for now it will require some development and creative research. I can offer you a few starting places to explore.
First, it sounds like it is possible for Elasticsearch to create a new index that searches over multiple existing ES indices - so it might be possible to to create a portal front-end that aggregates data from all of your "client" sites. However, this is not something we have explored yet, and I'm not sure how difficult it would be to combine 90+ indices all on different machines - you'll have to do some research!
You might be interested in looking at the University of British Columbia's OpenCollections website. They are aggregating data from multiple different platforms into one common, custom-built search interface. To gather data from AtoM, they are pulling it directly from Elasticsearch's API.
You can see here that an archival result gives returns basic information, and points the user to the relevant AtoM installation for further context and additional information:
Another option might be to see if you can use either AtoM's API, or the OAI harvesting module to automate data extraction from your client systems. See:
Finally, we do have some users who are making use of our replication script to manage a 2-site deployment - some large sites will use one read/write AtoM site internally for data creation and editing, and another read-only site for public use, combined with a replication script (that copies the database, digital objects, and search index to the public site) to sync them whenever it is triggered. Our replication script is available here:
None of these solutions will solve your use case out of the box - all will require analysis and further modification/development, but hopefully they might act as starting points for consideration.
We have previously discussed OpenCollections, as well as Simon Fraser University (who use the 2-site/replication script solution), in the following slide deck, in case it is of interest:
Note that in the Canadian context, some of the new import/export functionality included in the 2.4 release was added to offer better support for migrating select data from one AtoM instance to another. For example, you can configure what levels of description are included in an export, whether or not draft records are included, and more. See the import/export documentation for more details. It is a temporary solution, as so much manual data duplication is undesireable, but it will certainly require a lot more analysis and development to improve, which in turn will require community support for Artefactual to be able to address.
I hope this helps provide ideas, at least! Keep us posted on whatever solution you settle upon!
Cheers,