If it helps, I have published a Github Action that is creating the build-script from .travis.yml (ported from the original travis-build) and runs it. As I was running into the same kind of problem after migrating from travis-ci.org to travis.ci.com recently (support told me I should do so and while doing credits already ran out within less than three days):
The action allows to keep the same build script process across Travis and Github (as you know integration I guess this is an overstatement). As the cache / language configuration and matrix etc. is not done with this github action but only running the build-script / stages I was able to make the .travis.yml portable (e.g. I kept secrets out of the equation with little conditional edits) while creating the new workflow on Github.
This allowed me to switch off anything from Travis that is possible on Github already, e.g. I went down to 5 build minutes in total per build on Travis from what was 50+ minutes without first porting all the stage scripts (before_install, install, script etc.).
What still needs to be done in the Github workflow is the VM setup if it does not work out of the box, the checkout action and then other stuff like caches/services/matrix. But for caches for example I was first looking to get the build to work. So it’s helpful to do things step by step.
And yes, Travis has some features Github has not. With this action I could reduce to what I can not yet do on Github and keep the rest on Travis.
I will further reduce the Travis usage, that is when I have it triggered, next is only having build on tags. As only the stage scripts are re-used, changing the matrix in the .travis.yml does only touch Travis but not the Github workflow. This gives a lot peace of mind already.
My project is much smaller than yours, so your mileage may vary. I’ll do another project next and will take a look on the portability, it’s really new. But maybe it helps.
/Edit: running example: https://github.com/ktomk/pipelines/runs/1526326034?check_suite_focus=true#step:7:1