It may seem that "there ought to be a business model for an IT support firm that concentrates on legacy platforms like this", but personally I think that is just wishful thinking on your part as it would "solve" the challenges you face in one fell swoop.
Staying stuck in old environments is not the way to go forward. And I for one wouldn't bet the life of any company on trying to stay stuck by finding some firm that, for now, would be willing to do what you apparently can't.
So not an answer to the actual quesion you asked, but sincere advice on how you could move forward while keeping the risks of a migration to the minimum.
Read "How to survive a ground-up rewrite wihtout losing your sanity"
Don't make the error of a long migration project with no real results for a long time. Read "How to survive a ground-up rewrite wihtout losing your sanity"
I cannot stress enough how the advice in that article has helped me in tackling/approaching similar problems after burning myself doing those kinds of projects the "old" way.
Set up automated tests
If you haven't got it in place already (why ever not?), get your current programmers to create an automated test harness for your applications.
The automated test suite should cover all functional areas of your applications. It sh/would document the current working specifications in "when_X_then_Y" rules of the individual test cases. This will help both in keeping changes in your current code from breaking existing functionality as well as support any migration to a new environment.
As you are dealing with COBOL and BASIC, the test suite should probably be on the level of integration tests: working off a "fixed" set of input files/databases and checking the output files/changed database contents of specific programs (COBOL) and/or applications. For the BASIC parts of your software this may mean adding command line parameters to make them exercise certain functions without (G)UI intervention, or getting a (G)UI based automated test tool.
Isolate calculations and other algorithms
Even Cobol supports the notion of sub programs callable from a main program. Isolate all import calculations and other algorithms in separate programs or modules. Goal is to create a library of programs/modules/whatever that do the grunt work isolated from everything that gathers input and creates output.
Adapt the test harness to test them both through your old applications as well as in isolation. This will ensure that the work you are doing on the "old" code to facilitate migration to a newer environment will introduce as few errors as possible.
Start a new set of applications in a "current" environment
Don't convert your current code. Converting one language to another means imposing the constraints of the old environment on the new. The result if often less than desirable (read: the result will be terrible and a pain to maintain). Migrate. Take the time to set up your applications in the new environment in a way that is considered best practice for that environment.
Get new programmers, well versed in your chosen environment, in to do so. Make it a priority from day one to isolate all important calculations and algorithms in separate classes and/or packages and hide them behind interfaces. Use dependency injection (the cheapest kind of DIY dependency injection will do) to tell your new application which classes to instantiate/use to do the calculations.
This is a good way to do things anyway and in your case will allow you to migrate those important parts on a per case basis. It will also hide the intricacies of calling basic and/or cobol programs from the calling functions in the new environment.
Don't go any further that setting up the applications and perhaps setting up the single most important input/output function that uses a calculation from your COBOL/BASIC "library".
Integrate your COBOL/BASIC "library"
Figure out how to call your COBOL/BASIC "library" from your new environment. This may involve setting up parameter files or database tables, executing a COBOL/BASIC program that wraps the COBOL/BASIC library you set up earlier. If you are lucky your version of BASIC may allow for the creation of DLL's that can be called directly.
Implement the class in your new environment that will call the COBOL/BASIC "library" and test the heck out of it using the same tests that are in test harness of the old environment, but now in the form of unit tests in the new environment.
Yes this means "duplicating" the tests, but it is a safety net you don't want to do without. If only because these unit tests will later serve as the tests to check the implementation of your calculations and algorithms when they are migrated to your new environment.
But again: don't go any further than adding the unit tests for the calculation(s) used by the single most important from the previous step.
Flesh out the new applications in iterations
Flesh out the new applications by repeating the previous two steps for all functions in your old applications. Keep adding those unit tests that check the calculations to your new applications' test harness. Use the integration test suite to check that the migrated functions function the same as your old applications.
Migrate the core library in iterations
And finally migrate the calculations and algorithms in your COBOL/BASIC "library", re-implementing them in your new environment. Again, do this iteratively using the (unit) tests as a way to keep your sanity.
