So you "physically" pull the database [file] off the web server machine, open it, run an "Update" that pushes data from Access to Oracle (presumably through Linked Tables), then pull data from Oracle back into Access, then push the database [file] back onto the web server machine.
Let's ignore the potential for data loss caused by just splatting the database file back onto the web server, where it might have been updated since you last copied it ...
You could write a new program to automate the process of querying MySQL and updating data into Oracle, then reading Oracle and updating data into MySQL.
Many would advocate this and, most of the time, I probably would as well. However, you've got something that works, albeit involving Access, so here's an alternative ...
You could continue to leverage Access' Linked Tables feature.
You currently have "actual" tables in the Access database that you read and then push data [via Linked Tables] to Oracle. Then you pull data [via Linked Tables] from Oracle into those "actual" tables.
What's to stop you replacing those "actual" tables with more Linked Tables, pointing at the new, post-migration, "real" tables, held in MySQL? (Remember, Linked Tables like these might be a simple way of doing the actual migration to MySQL!)
You never copy a database file ever again. Just open the Access database and run your Queries.
Even better, write a Procedure in a Module in Access to run all those queries for you, completely automating the process so you literally just "push one button" and everything happens. And, in Access, you really can have that one Button. On a Form.
Better still, you could even write a small program (outside Access) to automate that automating Procedure and that program could be run by your company's Scheduling application - that way, you don't actually have to run this process at all any more!