So looking through osTicket, we've got a huge backlog of tickets which are purely import requests.
I was thinking about how many of these have files that we'll have to download and import. It's a lot of hassle to go through 10+ tickets, download however many XML or image dumps and run them individually. So I started thinking about a solution.
Could we create a (very simple) system that simply tracks a file against a wiki. My thinking was we can upload the files to the server (or wget them where possible) and use a special page to specify a file path (or create it one, move it there, verify it exists and then submit to DB) which is logged with the wiki name/DB. This then creates a job in a seperate queue which would be in $wgJobTypesExcludedFromDefaultQueue (because obviously importing a massive 2GB database dump on a random page load is going to suck) and the jobs are run occasionally by one of us. Makes it a lot easier so customer support can upload dumps without having to run the import, and makes it easier for sysadmins because we don't have to go and search for files in tickets.
Potential expansion for this means that if we've got a shared file server, or access to the files on the main server, we can throw these jobs on their own machine and avoid killing the production server.