Whenever the California state Legislature needed more money in its coffers, the DMV would pay for it in maintenance costs on its mainframe.

Why? With many applications built on COBOL, changes to the system could lead to time and money spent on altering those legacy applications. One of those changes which came about regularly was whenever the state would hike licensing fees.

But as James Taylor writes, companies can learn to make meals from their mainframe leftovers. What in the world does that mean? It means identifying which parts of your mainframe architecture are static and don’t require a lot of changes — and which do.

In the case of the California DMV, licensing changes were frequent. Other processes, such as the application managing vehicle information, didn’t change much.

And so mainframe migration doesn’t have to mean moving every process off big iron because a few are changing all the time and causing maintenance costs to increase. It means migrating only those oft-changing processes to a distributed platform, where changes might be easier, even if it’s only because of who the company has working for them and what skills they possess. As Taylor puts it:

However, more careful analysis can lead to an interesting insight - much of a typical mainframe system is static, works fine and needs no maintenance. Often only a small portion of the system is responsible for much of the maintenance work.