The framework isn't wrong. The unit of analysis is.
The 7Rs framework is one of the most widely used tools in cloud migration planning. Retire, retain, rehost, replatform, repurchase, refactor, re-architect. Clean categories. Logical progression. Works beautifully for microservices.
It breaks on COBOL.
Not because the framework is wrong. Because COBOL applications are not the unit of analysis. The component is.
When a cloud architect applies the 7Rs to an application portfolio, the implicit assumption is that each application is a discrete thing. One application, one decision. Retire it or rehost it. Move on.
This works for applications built in the last fifteen years. Modern applications tend to have clean boundaries – a service does one thing, owns its data, deploys independently. The 7Rs categories map naturally onto that architecture.
A COBOL application built over thirty years is not one thing.
It is a collection of programs, copybooks, JCL procedures, CICS transactions, DB2 stored procedures, and VSAM files that have accumulated business logic incrementally since before some of the people running the migration were born.
One application might be:
Applying a single 7Rs decision to that application is not a strategy. It is a guess. It is also how most migration budgets double.
Migration projects that go over budget and over schedule almost always have the same root cause: they discovered the complexity after the contract was signed.
The discovery happens when someone tries to move a "rehost" candidate and finds it calls a COBOL subprogram that calls a CICS transaction that reads a VSAM file that is also written by a batch job that was classified as "retire."
The dependency wasn't in the documentation. The documentation was written in 1994 and last updated in 2007. The person who knew about the dependency retired in 2019.
This is not an edge case. This is the normal condition of a mainframe COBOL estate that has been in production for more than twenty years.
The 7Rs framework doesn't cause this problem. But applying it at the application level instead of the component level guarantees you will discover the problem at the worst possible time.
To apply the 7Rs at the component level – which is the only level where it works for COBOL – you need to know what each component actually does in production.
Not what the documentation says it does. Not what the developer who wrote it thought it would do. What it actually does. At runtime. Today.
That requires runtime evidence:
SMF TYPE 30 records tell you which programs executed, when, how often, and how long they ran. A program that has zero SMF records in the last twelve months is dead code. That determination takes thirty seconds. Without SMF data, it takes a code review, a conversation with the application team, and three weeks of email.
CICS journals tell you which transactions are active, which are called by which other transactions, and what the actual call patterns look like under production load. Dependencies that are invisible in the source code are explicit in the journal.
Job logs tell you the actual execution path of every batch job – including the PROC members, the INCLUDE groups, the conditional JCL steps that only execute on month-end. The JCL in the source library is the template. The job log is what actually ran.
Start with the runtime evidence. Build the component map from what the system tells you, not from what the documentation claims.
There is a useful side effect of starting with runtime evidence.
Components with no runtime evidence but significant source code are a signal. Either the code is dead – in which case retire it – or it runs under conditions you haven't captured yet. Month-end processing. Disaster recovery procedures. Year-end batch runs.
That signal is worth investigating before the migration starts, not after the contract is signed.
Components with high runtime frequency and no documentation are a different signal. These are the programs the business depends on most. They are also the programs most likely to contain undocumented rules that will break in a new environment.
Runtime evidence doesn't eliminate the institutional knowledge problem. But it shows you exactly where the knowledge gaps are before you start. That is worth more than any amount of code analysis.
Before applying the 7Rs to a COBOL estate, do this first:
Extract twelve months of SMF TYPE 30 data. Identify every program that executed in production. Everything else is a retire candidate until proven otherwise.
Pull CICS journal data. Map the transaction call graph. Dependencies that don't appear in the source code will appear here.
Review job logs for the last complete business cycle – at minimum one month, ideally one year including quarter-end and year-end runs. The JCL in the source library is not the full picture.
Cross-reference. Programs that appear in source but not in SMF. Transactions that appear in CICS journals but not in the application inventory. Files that are written by jobs classified as retire and read by jobs classified as rehost.
Now apply the 7Rs. At the component level. With actual evidence.
The analysis takes longer. The migration costs less.
The 7Rs framework is not wrong. The unit of analysis is wrong.
A COBOL application is not a thing. It is a population of components with different ages, different purposes, different risk profiles, and different dependencies. Some of them haven't run in years. Some of them process more transactions before breakfast than most cloud applications handle in a week.
Treat them accordingly.
Understanding the COBOL is step one. There are nine more steps. The one most migration projects skip is step zero: find out what the COBOL actually does before you decide what to do with it.
IMUAI uses SMF data, CICS journals, and job logs to map what your mainframe actually does – not what the documentation says it does.
Learn about IMUAIIM3270 is a modern 3270 terminal emulator for Linux. Free 60-day trial.
Download IM3270 Free