I've spent a lot of my career updating/fixing/replacing aging PHP apps, so here are some pointers:
0. Ignore PHP8 for now. There's much more community support for PHP7, so fix it up to work on PHP 7.4 first.
1. My first task is always to use a code scanner to test if the codebase is PHP7 compatible (or PHP 5.6, or the next version on from whatever you're running). See https://blog.fortrabbit.com/php-testing for an incomplete list (I've used others but haven't got my bookmarks to hand). You'll get false positives but also a good feel for whether there are serious issues.
2. You don't say if it's a CRUD app or an API. If it's the latter: set up a PHP 7.4 box (with a copy of the datastore) and route all traffic to the current production box and to the copy. Save the responses from both and compare they're the same. A simple way to see if the app will work on PHP, and when you find something that's broken, you can fix it, reset the logs, and try again. Hard(er) to do with CRUD, but I have compared the datastore contents before to check they're the same.
3. Needless to say, stick it all in source control if it's not already.
4. For your own sanity, run a code formatter over it if the code is messy.
5. I like PhpStorm as an IDE. It's not free, but the intellisense and refactoring support (and the built-in debugger) are timesavers.
6. Assuming it's not global variables everywhere, that they've used functions/classes(!), then as you fix bits of the code rename the single letter variables and add comments. PhpStorm can refactor variable names, so you see what will change before it happens.
8. Good luck! I like unpicking codebases like this and keeping them running. As a sibling commenter has said, it's an internal system so assuming staff are not going to exploit any vulnerabilities or you have guarded against those already, there is no problem keeping it running internally as-is. So long as you can still recreate the VM from scratch (I have had old packages disappear - now that makes for an interensting disaster recovery plan) and reinstall everything you need should backups fail, you're okay.
Correct, it's not free, but there is a 30 day trial. And... if you want to try it past that, it's $9/month on month-to-month pricing. For anyone working in "western" economies, it's near enough to free to at least give it a trial for a few months. The other 'big' competitors - vscode and probably... eclipse - both can provide value, but I've found the JetBrains stuff provide a much nicer out of the box experience for most PHP folks getting started out that that $89/year or $9/month to try is almost a no-brainer. But have also had people disagree, and almost always spend more than the $89 of their own time (or their company's time) getting VSCode set up with a collection of plugins.
Regarding mysql* i 'd guess it's probably easier to just replace it with mysqli_* calls. Only a few changes would be needed unless the app is doing something unconventional.
0. Ignore PHP8 for now. There's much more community support for PHP7, so fix it up to work on PHP 7.4 first.
1. My first task is always to use a code scanner to test if the codebase is PHP7 compatible (or PHP 5.6, or the next version on from whatever you're running). See https://blog.fortrabbit.com/php-testing for an incomplete list (I've used others but haven't got my bookmarks to hand). You'll get false positives but also a good feel for whether there are serious issues.
2. You don't say if it's a CRUD app or an API. If it's the latter: set up a PHP 7.4 box (with a copy of the datastore) and route all traffic to the current production box and to the copy. Save the responses from both and compare they're the same. A simple way to see if the app will work on PHP, and when you find something that's broken, you can fix it, reset the logs, and try again. Hard(er) to do with CRUD, but I have compared the datastore contents before to check they're the same.
3. Needless to say, stick it all in source control if it's not already.
4. For your own sanity, run a code formatter over it if the code is messy.
5. I like PhpStorm as an IDE. It's not free, but the intellisense and refactoring support (and the built-in debugger) are timesavers.
6. Assuming it's not global variables everywhere, that they've used functions/classes(!), then as you fix bits of the code rename the single letter variables and add comments. PhpStorm can refactor variable names, so you see what will change before it happens.
7. If the code's using mysql_* functions, which aren't present in PHP7, there's a shim to make them work: https://github.com/dshafik/php7-mysql-shim
8. Good luck! I like unpicking codebases like this and keeping them running. As a sibling commenter has said, it's an internal system so assuming staff are not going to exploit any vulnerabilities or you have guarded against those already, there is no problem keeping it running internally as-is. So long as you can still recreate the VM from scratch (I have had old packages disappear - now that makes for an interensting disaster recovery plan) and reinstall everything you need should backups fail, you're okay.