I've done similar projects with smaller file sizes - pulled a few thousand organization's worth of data together, transformed it to a single common structure, and published it online.

Shipping data was the easy part - if it is small enough to attach to an email, do so. Otherwise send us a USB. Like you said, if the org have no in-house tech, even getting them to sync on Dropbox was more trouble than having them send a USB.

For the actual data ingestion, we did not use any existing tech. We wrote a series of API calls that would take a specific data structure and put that data in our system in a common format. We then wrote scripts that would handle different types of incoming data, whether that is CSV, SQL DBs, binary files, or really anything they chose to send us, and transform it to our needed structure. We took the burden on ourselves of reading their files or standing up DB servers and writing SQL commands to pull the data into the shape we needed, and passing it to our scripts.

While that sounds like a lot of one-off work (and it was), there are not that many formats they are going to send you - outside of CSVs, Zip files, and database archives... non-tech folk really aren't going to come up with anything too crazy. (The only outrageous formats we got were from coders.) So write a script for the first one, then adjust the code for the next. The time you spend looking for tech that will slice and dice it just the way you want is probably not all that different than just writing import scripts.

All that to say - you might want to approach this not as one large data effort, but as 3000 small efforts. Re-use code where you can, streamline the processes as you go, automate it where possible. But don't over-engineer a solution before you even do your first import. Just get rolling, and the opportunities to streamline the efforts will become evident as you progress.