We are a small, very specialized, benefits administration firm with an extremely useful, robust collection of software, some written in COBOL but most in BASIC. Two full-time consultants have ably maintained and improved this system over more than 30 years. Needless to say they will soon retire. (One of them has been desperate to retire for several years but is loyal to a fault and so hangs on despite her husband's insistence that golf should take priority.)

We started down the path of converting to a system developed by one of only three firms in the country that offer the type of software we use. We now feel that although this this firm is theoretically capable of completing the conversion process, they don't have the resources to do so timely, and we have come to believe that they will be unable to offer the kind of service we need to run our business. (There's nothing like being able to set one's own priorities and having the authority to allocate one's resources as one sees fit.)

Hardware is not a problem--we are able to emulate very effectively on modern servers. If COBOL and BASIC were modern languages, we'd be willing to take the risk that we could find replacements for our current consultants going forward.

It seems like there ought to be a business model for an IT support firm that concentrates on legacy platforms like this and provides the programming and software development talent to support a system like ours, removing from our backs the risks of finding the right programming talent and the job of convincing younger programmers that they can have a productive, rewarding career, in part in an old, non-sexy language like BASIC.

In short, as non-IT managers, how can we best manage this transition?

  • 6
    ouch! BASIC and COBOL?!? I would try a retirement home. Have you thought of "modernizing" your software? Commented Oct 25, 2013 at 6:12
  • 2
    Just to add : productive, rewarding career, in part in an old, non-sexy language like BASIC. -- BASIC and productive, rewarding career do not go along in one sentence Commented Oct 25, 2013 at 6:14
  • 3
    There are lots of contractors and consultancies that migrate software form legacy systems. However cobol and basic are not legacy they are prehistoric. Although weirdly its probably quite easy to hire someone, as they are probably cool in a hipster hacker way. Commented Oct 25, 2013 at 6:34
  • 3
    I'm going to agree with @BЈовић on this one. You should consider modernizing your software rather than trying to find life support for something as ancient as BASIC and COBOL, for the sake of future proofing at least. For now you might find some oldies or hipster kids who can code for you, but as years pass by and paradigms change, these talents will become endangered species which will in turn cause the slow and steady demise of your system. The mere fact that you can barely find programmers now should be a red flag that its about time for a change.
    – Maru
    Commented Oct 25, 2013 at 8:59
  • 2
    @user105977 - My best advice would be to document the current system ( if its not already documented ) so that your consultants feel confortable, if they were hit by a bus or retire, somebody could come in after them and manage the project. Once you have documentation of the project ( specifications, project requirements, ect ) you are not in such a bad position. I sort of disagree with most of the comments about these languages, there is still demand for them, and knowlege of these languages is worth a great deal of money. A young developer should be able to learn these languages quickly.
    – Ramhound
    Commented Oct 25, 2013 at 11:59

3 Answers 3


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.

  • 1
    While your answer is good when seen for itself, it unfortunately doesn't really focus on the question. The asker is a non-IT manager who quite likely has no idea what you mean with most of what you wrote. He needs advise for finding someone who does.
    – Philipp
    Commented Oct 25, 2013 at 12:02
  • 1
    @Philipp: Well spotted even though I did say that I wasn't answering his actual question. I am sure OP knows how to use Google and there are enough search terms in my answer for OP to start some research - or better yet - have the current programmers do so. Do feel free to add your own answer addressing OP as you think it needs to be done though. Heck, might even upvote if you did... Commented Oct 25, 2013 at 12:09
  • He'll need a business IT consultant for the transition process, one who has assisted in such processes before. The consultant shouldn't be doing the work, but instead should find the people doing the work, supervise them, and make sure that the program does what's required for the business. Yes, that's expensive. Having your own software always is.
    – MSalters
    Commented Oct 25, 2013 at 15:34
  • @MarjanVenema (I don't know exactly what I was expecting when I posted this question, but one thing I wasn't expecting was that almost every comment would be thoughtful and useful--many thinks to all.) I read your recommended "how to survive" post by Milstein, and the Spolsky post he was responding to, and not even Milstein likes the idea of rewriting code. Based on our experience so far, Spolsky's comments about the perils of data migration and the value of working code ring true. I am definitely worried that I am succumbing to wishful thinking but I really want to think Ramhound's right.
    – user105977
    Commented Oct 27, 2013 at 5:29
  • 1
    @user105977: I understand. Yes a rewrite is risky, but not always avoidable and sometimes the best way forward despite the risk. To me keeping the old system(s), relying on a skillset that even now is not exactly readily available, is a business risk that may be greater than the risk of a rewrite and one that increases with time as the pool of available developers keeps decreasing. But I am not in your position and cannot judge their relative risk. Commented Oct 27, 2013 at 10:40

It sounds like this application is "core" to your business. In cases where a system or process is what IS your business that is a case for having your own custom solution.

You alluded to this. Unfortunately given the lengthly time you have gone since updating your technologies, this will be an extremely difficult undertaking.

I would recommend one of two routes.

  1. Staff up an IT group of developers/project managers/QE/operations and build out your system incrementally, as noted in the rather technical answer above. This will however, be exceptionally expensive.
  2. Rather than an off the shelf provider, look for a qualified custom developer consultant. This group will handle all of the resources to build out your new system, then you can bring it in house with a small staff than option 1 to continue. This option has a different set of risks however, selecting a good provider can be very difficult for the non-technical. They can also be very high risk with cost overruns etc. To mitigate this route, use your existing staff to craft a very detailed set of requirements (from the user perspective) for your bid. Then ask for fixed price bids as well.

Good luck, you have about 20 years of legacy to overcome. It will not be cheap, easy, or clean.

  • 1
    FYI: 20 years in the software world is equivalent to 2 or 3 human generations. It's a very very long time. From a technological point-of-view, BASIC and COBOL are old enough to be put in a museum... Commented Oct 25, 2013 at 18:52
  • I have been programming for 20 years now actually and COBOL predates my experience quite a bit. Commented Nov 1, 2013 at 6:51

Rather than look for a firm to maintain your legacy software or for a firm to rewrite your legacy software, look for a firm to provide a continued benefits administration system service. Outsource the problems of deciding whether or not to rewrite the software, what schedule to set, which language(s) or tools to use.

Yes, the obvious costs of this approach might exceed the obvious costs of hiring new programmers but, by your own admission you are a non-IT manager and it is easy to foresee scenarios in which you make decisions that ultimately cost your company more than the obvious costs of outsourcing.

  • 1
    The second paragraph states that they've already done what you suggest: they have identified all three firms which provide benefits administration software. None of them qualified.
    – MSalters
    Commented Oct 25, 2013 at 15:31
  • I didn't suggest they find a firm to provide software, rather a continued benefits administration system service. Commented Oct 25, 2013 at 19:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.