You will have solved the easiest part. Now get started on replicating JCL, VSAM, CICS, IMS, RACF, and the rest of the ecosystem that COBOL code depends on :)
Back in the late 90s I had the bright idea of shipping our COBOL runtime as a browser plugin. This worked relatively well for a fraction of our customers since we had a transparent remote ISAM & RPC system the plugin could use (the idea being that the browser plugin meant you only had to update your Windows desktop clients with new versions of the runtime; they'd get the latest app on load) but the rest had a huge thicket of system-level dependencies which made that hard to consider, and that was for customers who'd already been able to migrate off of mini/mainframe systems to Unix.
At this point in time, the mistake is to hear “COBOL” and think about a programming language rather than environments where they've struggled to manage technical debt and staffing issues for decades. It's not that COBOL developers can't produce good code but rather than places which can modernize effectively did so 3+ decades ago. If some place makes the news now because of a COBOL-based system, COBOL is a symptom of a management failure.
Ah, a cobol browser plugin? Cool. And yeah, environments. It's like porting JS to the mainframe, but not providing the POSIX facade to allow it to make files, schedule batch jobs, kill processes, connect to the network, store data in a database, access rights, auth, etc.
Yes – AcuCOBOL had a COBOL development system which was byte-coded like Java (the technical founder had actually overlapped with Gosling in undergrad, I believe) so we already had the capability to copy the compiled program onto most platforms (Most Unix variants, VMS, Win16 and Win32, OS/2, DOS, OS/400, etc.) and launch it with the native runtime. There was also some ability to transparently redirect I/O — you could have any CALL which didn't wasn't in the local compiled code do an RPC call to a remote server, and redirect some or all ISAM operations to either a remote server or (with another license) a SQL database.
Once they had that infrastructure, it wasn't a huge amount of work to package the runtime as a plugin which was configured to enable the remote call & I/O options by default. Which is exactly restating your last point: having already done the hard 95% of the work, this part was straightforward.
At this point in time, the mistake is to hear “COBOL” and think about a programming language rather than environments where they've struggled to manage technical debt and staffing issues for decades. It's not that COBOL developers can't produce good code but rather than places which can modernize effectively did so 3+ decades ago. If some place makes the news now because of a COBOL-based system, COBOL is a symptom of a management failure.