How to hire COBOL developers in 2026: A sourcing guide

COBOL was created in 1959. It predates the internet, personal computers, and the moon landing. Sixty-seven years later, it still processes more financial transactions daily than any other language on Earth. JPMorgan Chase, Bank of America, Citigroup, Wells Fargo, HSBC, Visa: their core transaction systems run on COBOL. So do the IRS's Individual Master File, the Social Security Administration's 60 million lines of benefits processing code, and at least a dozen state unemployment systems.

This is not a legacy technology story. It is a $3 trillion daily infrastructure story with a shrinking workforce and no pipeline. When New Jersey's unemployment system crashed during COVID, Governor Murphy publicly called for volunteer COBOL programmers. It made national news, but the crisis had been building for decades. When DOGE attempted to rewrite the Social Security Administration's COBOL codebase in months during 2025, experts pointed out that testing alone would take years. The systems are too large, too intertwined, and too critical to replace on political timelines. They need people who know how to maintain them, and those people are retiring.

If you are sourcing COBOL talent for the first time, this guide is for you. We covered niche language sourcing strategies previously, but COBOL is a different category entirely. It is not a niche language adopted by forward-thinking startups. It is the foundation of the global financial system, staffed by a workforce that is aging out faster than it can be replaced. The sourcing strategies, channels, and evaluation criteria look nothing like what you are used to for other languages. If you are also new to GitHub as a recruiting channel, we will cover how that applies to COBOL as well. It is a smaller but growing source of mainframe talent.

The COBOL developer market in 2026

The most commonly cited figure for the global COBOL workforce is 2 million, from a Gartner estimate in 2004. Nobody has re-counted at that scale since. In the US, the active COBOL workforce is roughly 24,000 developers. The average age is 58, according to the Teplitzky study of mainframe professionals. About 10% retire each year. By the end of 2026, an estimated 30 to 40 percent of the 2019 COBOL workforce will have retired or be on their way out.

The codebase they are leaving behind is enormous. Estimates range from 220 to 800 billion lines of COBOL in production worldwide. Five billion new lines are added per year. This is not a static codebase being gradually replaced; it is actively growing. New business logic, regulatory changes, product updates, integrations with modern systems. The language is not dying. The workforce is.

Compensation reflects the scarcity. US COBOL developer salaries average $105,000 to $125,000 per year. Senior developers with deep mainframe expertise (CICS, DB2, IMS, z/OS internals) command $155,000 to $188,000, and those numbers are climbing 10 to 15 percent annually as the talent pool contracts. Contract rates run $50 to $83 per hour. These figures are competitive with or above many modern language roles, but the perception that COBOL work is outdated keeps suppressing the pipeline of new entrants.

Demand is not shrinking either. Industry projections put the number of unfilled mainframe positions at 84,000. Seventy percent of organizations report difficulty finding mainframe modernization skills, and 91% expect to need mainframe staff within one to two years. These come from workforce surveys of enterprises that run production COBOL systems and cannot find people to maintain them.

The pipeline problem is structural. IBM's Z Academic Initiative spans 120-plus schools. The Master the Mainframe program graduated 4,286 students. These are real efforts, but the annual throughput is a fraction of the retirement rate. Almost no universities teach COBOL in their standard CS curricula, and younger developers see mainframe work as unglamorous despite salaries that match or exceed many cloud-native roles. The result: demand is growing, supply is shrinking, and nothing currently underway is large enough to close the gap.

Where COBOL infrastructure runs

Knowing where COBOL runs matters for sourcing because it tells you which industries, companies, and systems your candidates have likely worked on. Unlike modern languages where GitHub repositories map to employer domains, COBOL expertise maps to industries and platform stacks.

Banking and financial services. This is where most COBOL lives. JPMorgan Chase, Bank of America, Citigroup, Wells Fargo, HSBC, Visa, Fiserv, and American Express all run core transaction processing on COBOL. Forty-three percent of US banking core systems are COBOL. Eighty percent of in-person transactions (ATM withdrawals, card swipes, wire transfers) touch COBOL code somewhere in the processing chain, and the daily volume in financial services alone runs into the trillions. If your candidate worked at a large bank on "core banking" or "transaction processing," they almost certainly wrote COBOL.

Insurance. A CAST study of 250 applications across 38 organizations found that 69% of insurers run COBOL applications. Policy administration, claims processing, underwriting engines, billing systems. The pattern is similar to banking: massive codebases, decades of accumulated business logic, and regulatory requirements that make replacement projects high-risk and multi-year.

US government. The IRS Individual Master File, which processes every federal tax return, runs on COBOL. The IRS has been converting roughly 90% or more of it to Java, targeting 2028 for completion. The Social Security Administration runs over 60 million lines of COBOL with a custom database system called MADAM. State unemployment systems in New Jersey, Connecticut, Florida, Kansas, California, Rhode Island, and Iowa are COBOL-based, many of them 40-plus years old. Medicare and Medicaid processing depends on COBOL too. Government COBOL systems are among the largest and most complex anywhere, maintained by some of the most experienced developers in the workforce.

Airlines and travel. The SABRE reservation system, originally built for American Airlines in 1960, was one of the earliest large-scale COBOL applications. Global distribution systems (GDS) that power airline booking, hotel reservations, and car rentals have COBOL in their transaction processing layers. Newer systems have replaced some of this infrastructure, but core booking and settlement at several major airlines still runs on COBOL.

The aggregate numbers. An estimated $3 trillion in daily commerce flows through COBOL systems. Ninety-five percent of ATM transactions involve COBOL processing, a figure from a 1997 Gartner survey of 421 companies, later cited by IBM and Reuters. No equivalent survey has been conducted since, so it remains the reference point. Seventy to 80 percent of global business transactions touch COBOL at some point. These are not theoretical estimates. They describe the actual infrastructure that processes money, benefits, insurance claims, and tax returns.

COBOL on GitHub

If you are used to sourcing developers on GitHub (and if you are not, our GitHub recruiting guide covers the basics), COBOL's presence there will look unusual. GitHub is dominated by JavaScript, Python, Go, Rust, TypeScript. COBOL lives primarily on IBM mainframes behind corporate firewalls, and the vast majority of production COBOL code will never appear on GitHub. But there is a growing open-source COBOL community, and it contains signal worth sourcing.

GnuCOBOL. GnuCOBOL is a free, open-source COBOL compiler that transpiles COBOL to C and compiles with GCC, letting COBOL programs run on Linux, macOS, and Windows without a mainframe. It is under active development. Its contributor base includes experienced mainframe developers and newer programmers learning COBOL through open source. If someone contributes to GnuCOBOL, they understand COBOL at the compiler level.

Open Mainframe Project. Hosted by the Linux Foundation under the GitHub organization openmainframeproject, this is an umbrella for multiple open-source mainframe initiatives: development tools, testing frameworks, integration utilities. Contributors tend to be working professionals who understand both mainframe infrastructure and modern development practices. That is the "bilingual" profile that is hardest to find and most worth hiring.

COBOL Check. A unit testing framework for COBOL, part of the Open Mainframe Project. Unit testing in COBOL has always been hard because the language predates modern testing methodologies. Developers who contribute to COBOL Check are bringing modern software engineering practices to a 67-year-old language, which says something about both their COBOL depth and their development habits.

COBOL Programming Course. The Open Mainframe Project hosts a three-course COBOL learning series on GitHub, updated in 2024 with Zowe V3 integration and GitHub Actions CI/CD pipelines. Students may be early in their COBOL journey, but contributors who maintain and update the course material, especially those integrating modern tooling, show teaching ability and cross-platform know-how.

Zowe. Zowe is an open-source framework for integrating mainframe systems with modern development tools. It provides CLI tools, APIs, and IDE extensions (including VS Code) that let developers interact with z/OS without the traditional 3270 terminal. Zowe contributors are building the bridge between mainframe and modern workflows. If your organization is modernizing its mainframe infrastructure, these are exactly the people you want to talk to.

SuperBOL. SuperBOL, developed by the French company OCamlPro, provides advanced COBOL development tools including a language server protocol (LSP) implementation. This enables code completion, diagnostics, and navigation in modern IDEs for COBOL. Contributors work at the overlap of language tooling and COBOL, a small and specialized group.

Docker-based COBOL development environments. Multiple GitHub repositories provide Docker containers preconfigured with GnuCOBOL and related tools, making it possible to learn and develop COBOL without a mainframe. Contributors to these projects understand both containerization and COBOL toolchain setup, another "bilingual" signal.

How do you tell a real COBOL developer on GitHub from a student who completed a tutorial? Look for contributions to GnuCOBOL, Zowe, or Open Mainframe Project repositories. Look for COBOL code that integrates with JCL, CICS, or DB2. That indicates mainframe production experience, not just syntax knowledge. Mainframe modernization tools, COBOL-to-Java migration utilities, API wrappers around legacy systems: these are artifacts of working professionals.

Quality signals for COBOL developers

Evaluating COBOL developers requires a different framework than modern languages. General seniority signals still apply (code review participation, cross-project contributions, documentation quality), but COBOL expertise is measured primarily by depth of mainframe platform knowledge, not language syntax. A developer who knows COBOL syntax but has never written JCL or configured a CICS region is not ready for production mainframe work.

COBOL programming: batch and online. COBOL applications fall into two categories. Batch processing runs scheduled jobs that process large volumes of data, typically overnight: sequential file handling, sort/merge operations, report generation. Online processing handles interactive transactions, typically via CICS: screen design, transaction management, real-time data access. An experienced developer understands both and knows when to use each. Most production environments use both, and a senior developer is comfortable designing and debugging in either context.

JCL (Job Control Language). JCL tells the mainframe how to run COBOL programs: what datasets to read, what resources to allocate, how to handle errors, how to chain jobs together. It is not COBOL itself, but no COBOL program runs in production without it. A developer who cannot write and debug JCL cannot operate independently on a mainframe. JCL expertise (dataset management, job scheduling, ABEND handling, GDG management) is a non-negotiable marker of production mainframe experience.

CICS (Customer Information Control System). CICS is IBM's online transaction processing system. It sits between COBOL programs and terminal users or other systems, handling transaction management, screen presentation (via BMS maps), data access, and inter-program communication. A developer with CICS expertise understands pseudo-conversational programming, task control, and CICS command-level API calls. This is what separates batch-only developers from those who can work on interactive transaction systems: ATM interfaces, teller applications, online banking backends.

DB2. IBM's relational database is the most common data store for mainframe COBOL applications. COBOL programs access DB2 through embedded SQL. A skilled developer understands query optimization, EXPLAIN analysis, locking and concurrency, and the performance implications of different access paths. DB2 expertise matters most on high-volume transaction systems, where a poorly written query can degrade performance across the entire mainframe LPAR (Logical Partition).

IMS (Information Management System). IMS is IBM's hierarchical database and transaction manager, predating DB2. Many older mainframe applications, especially in banking and insurance, still use IMS DB (the database component) and IMS DC (the transaction manager, similar in function to CICS). IMS expertise is rarer than DB2 expertise. Developers who understand IMS segment structures, DL/I calls, and IMS transaction flow are in exceptionally high demand.

VSAM (Virtual Storage Access Method). VSAM is the file management system on mainframes: indexed, sequential, and relative record access. COBOL programs read and write VSAM files constantly. An experienced developer understands VSAM file types (KSDS, ESDS, RRDS), performance tuning (CI/CA splits, buffer allocation), and the IDCAMS utility. VSAM knowledge is a baseline expectation for any mainframe COBOL developer.

TSO/ISPF. TSO (Time Sharing Option) and ISPF (Interactive System Productivity Facility) are the interactive development environment on z/OS mainframes. ISPF panels are how developers edit code, submit jobs, browse datasets, and navigate the system. Younger developers increasingly use Zowe and VS Code extensions, but experienced developers are fluent in ISPF. Someone comfortable with both traditional ISPF and modern Zowe-based workflows can work in any mainframe shop.

Development and debugging tools. Production mainframe environments rely on specialized tools: File-Aid for data inspection, Xpediter (Compuware/BMC) for interactive debugging, Jobtrac or CA-7 for job scheduling, Syncsort/Syncsort MFX for high-performance sorting, and IDCAMS for VSAM administration. Knowing these tools means a developer has worked in real production environments, not training labs. If a candidate mentions Xpediter or File-Aid in conversation, they have spent real time debugging production COBOL.

The "bilingual" developer. The hardest profile to find. This person writes COBOL and JCL but also knows Java, Python, or cloud platforms. They can design APIs that wrap legacy COBOL programs, plan and execute COBOL-to-Java migrations, set up CI/CD pipelines for mainframe code using Zowe and Jenkins. They command the highest salaries because they bridge the gap between the mainframe team and the cloud team, a gap that exists in virtually every large enterprise. If you find one, move fast. Everyone else is looking for the same person.

Modernization and what it actually means

COBOL modernization is not replacing COBOL. It is changing how COBOL systems are accessed, integrated, maintained, and sometimes incrementally migrated. This matters for sourcing because it creates a second demand vector for COBOL talent: not just maintaining existing systems, but transforming them.

IBM watsonx Code Assistant for Z. IBM's AI-assisted tool for mainframe modernization reports a 79% reduction in code comprehension time and a 60% productivity increase in COBOL-to-Java transformation. It helps developers understand existing COBOL codebases, which matters because many of these systems have minimal documentation and were written by people who retired decades ago. The tool does not eliminate the need for COBOL expertise. It makes existing experts more productive and cuts ramp-up time for developers learning legacy codebases.

TCS MasterCraft TransformPlus. Tata Consultancy Services offers a modernization platform claiming 60 to 80 percent automation of COBOL transformation tasks: code analysis, refactoring, migration to Java or cloud-native architectures. Large enterprises, particularly in banking and insurance, engage TCS and similar firms for multi-year modernization programs. Developers who have worked on these programs understand both the source (COBOL/mainframe) and target (Java/cloud) environments.

Major consulting and services firms. Accenture, IBM Global Services, DXC Technology, Astadia, Micro Focus (now OpenText), and several smaller specialized firms all have mainframe modernization practices. These firms employ a significant portion of the remaining COBOL workforce, either as full-time consultants or as contractors on client engagements. Former consultants from these firms are a good candidate pool. They have typically worked across multiple client environments and know a range of mainframe configurations.

The bottom line for sourcing: modernization does not eliminate the need for COBOL developers. It increases demand for people who understand both worlds. Every modernization project starts with code comprehension, understanding what the existing COBOL does, what business rules it encodes, how it connects to other systems. That requires COBOL expertise. The target state (Java, cloud, APIs) requires modern skills. The transition requires both. The "bilingual" developer is the one every modernization program needs and few can staff.

How to search for COBOL developers

COBOL sourcing requires multiple channels. Unlike modern languages, most COBOL developers are not on GitHub, do not maintain personal websites, and are not active on Stack Overflow or Hacker News. The standard playbook of searching GitHub, cross-referencing LinkedIn, and sending outreach covers only a fraction of the available talent. Here is where to look.

GitHub. The COBOL community on GitHub is small compared to modern languages, but it is growing and contains high-signal candidates. Search for contributors to GnuCOBOL, Zowe, Open Mainframe Project repositories, and COBOL-related tools. If you are not familiar with using GitHub for recruiting, our GitHub recruiting guide covers the basics. For COBOL specifically, GitHub surfaces the subset of mainframe developers who are engaged with open-source tooling and modern development practices. These are disproportionately the "bilingual" profile that modernization projects need.

IBM Z Academic Initiative alumni. IBM's academic program spans 120-plus schools and introduces students to mainframe technology, including COBOL. The Master the Mainframe program (now IBM Z Xplore) has graduated 4,286 students. These alumni are the primary pipeline of younger COBOL talent, reachable through LinkedIn, university career services, and IBM's own networks. They tend to have foundational COBOL and z/OS knowledge but may need mentorship on production systems. For organizations willing to invest in ramp-up, this is the most scalable source of new COBOL talent.

Mainframe user groups and conferences. SHARE, founded in 1955, is the oldest and largest mainframe user group. GSE (Guide Share Europe) covers the European community. Both host conferences and maintain member directories. Speaker lists, session presenters, and working group participants are publicly or semi-publicly available. Regional mainframe user groups exist in many major cities too. Most recruiters ignore these channels entirely because they focus on online sourcing.

Retired developers willing to contract. COBOL Cowboys is a network of over 700 experienced mainframe professionals, many semi-retired but available for contract work. A significant number of retired COBOL developers will take contract or part-time work, especially for interesting modernization projects or system emergencies. If you need immediate expertise and cannot wait for a full-time hire to ramp up, retired developers as contractors or mentors can bridge the gap.

Younger developers learning through open source. The COBOL Programming Course on GitHub (Open Mainframe Project) has active students learning COBOL through hands-on exercises with modern tooling: VS Code, GitHub Actions, Zowe. They are early in their COBOL journey but bring modern development practices and a willingness to learn. For long-term workforce planning, identifying and engaging these learners early through internships, mentorship programs, or junior roles builds a pipeline that compounds over years.

Cross-referencing modernization project alumni. Developers who have worked on COBOL modernization at consulting firms (Accenture, IBM, DXC, TCS, Astadia) have direct experience with both legacy and modern systems. LinkedIn searches for "COBOL modernization," "mainframe migration," or "COBOL to Java" surface candidates who have done this professionally. Former consultants are especially useful because they have typically worked across multiple client environments and can adapt to different mainframe configurations quickly.

A practical COBOL sourcing workflow

Here is what works, from defining the role to scaling your outreach.

Step 1: Define the technical profile. "COBOL developer" is not specific enough. Are you hiring for maintenance of existing production systems (batch processing, CICS online transactions, JCL management)? Modernization (COBOL-to-Java migration, API wrapping, cloud integration)? Both? Maintenance roles require deep mainframe expertise in CICS, DB2, JCL, VSAM, and prioritize reliability over innovation. Modernization roles need the "bilingual" profile: COBOL understanding plus Java, cloud, or API development skills. Many organizations need both, but the sourcing channels and evaluation criteria differ.

Step 2: Identify target systems and technologies. COBOL is not monolithic. Which dialect does your environment use? Enterprise COBOL for z/OS, Micro Focus COBOL, GnuCOBOL, and COBOL-IT all have differences. Which mainframe platform: z/OS, z/VSE, z/TPF, or IBM i (formerly AS/400)? Which databases: DB2, IMS, VSAM, Adabas? Which transaction monitor: CICS or IMS DC? A candidate with deep DB2 expertise may have limited IMS experience. A developer experienced with z/OS may not know z/VSE. Being specific about these requirements prevents wasted interviews and helps candidates self-select.

Step 3: Source from multiple channels at once. Do not rely on one channel. Run parallel sourcing across GitHub (GnuCOBOL, Zowe, Open Mainframe Project contributors), IBM academic program alumni (LinkedIn, university career services), mainframe user groups (SHARE, GSE, regional groups), retired developer networks (COBOL Cowboys, personal referrals), and modernization project alumni (consulting firm searches on LinkedIn). Each channel reaches a different segment of the COBOL workforce, and the overlap is small. A GitHub-active Zowe contributor and a retired IBM mainframe specialist are both viable candidates but will never appear in the same search.

Step 4: Evaluate on mainframe depth, not just COBOL syntax. A candidate who can write syntactically correct COBOL but has never submitted a JCL job, debugged a CICS ABEND, or tuned a DB2 query is not ready for production work. Your evaluation should cover platform knowledge (z/OS, TSO/ISPF, JES2/JES3), database expertise (DB2, IMS, VSAM), transaction processing (CICS or IMS DC), and operational experience (ABEND handling, job scheduling, performance tuning). For modernization roles, add Java, REST APIs, CI/CD, and cloud platform assessment. A structured technical screen with mainframe-specific questions will tell you more than a generic coding exercise.

Step 5: Expand to adjacent backgrounds. Given the supply constraints, consider candidates who are not currently COBOL developers but could become effective ones. Java developers willing to learn mainframe, particularly those from banking or insurance who already understand the business domain, can ramp on COBOL with structured training (IBM offers courses, and open-source resources like the COBOL Programming Course are available). CS students from IBM Z Academic Initiative schools have foundational mainframe knowledge. Developers from other legacy platforms (Natural/Adabas, PL/I, RPG on IBM i) share mental models with COBOL developers and transition with less ramp-up than developers from purely modern backgrounds.

Step 6: Craft outreach that shows you understand the work. COBOL developers, especially experienced ones, receive recruiter messages that make it obvious the recruiter does not understand what they do. "I see you have experience with legacy systems" is the COBOL equivalent of "I see you know JavaScript." Good outreach references specifics: "We're looking for someone with CICS command-level experience and DB2 query optimization skills for our core banking transaction processing system on z/OS." Mention the mainframe platform, the databases, the transaction monitor. If you are reaching out to a GitHub contributor, reference their actual contributions. Our guide to recruiter emails developers actually respond to covers the principles. For COBOL developers, the bar for technical specificity is high because the community is small and experienced developers can immediately tell whether you know what you are talking about.

Step 7: Scale with tooling. For the GitHub-discoverable subset of COBOL talent (contributors to GnuCOBOL, Zowe, Open Mainframe Project, and other open-source mainframe projects), tools like riem.ai can automate discovery by analyzing GitHub contribution data at scale. Describe the technical profile in natural language ("developers contributing to mainframe modernization tools, COBOL compilers, or z/OS integration frameworks") and get a ranked list with contribution summaries and quality scores. This does not replace the multi-channel approach above. Most COBOL developers are not on GitHub. But it systematically covers the open-source channel that manual searches often miss.

Frequently asked questions

How many COBOL developers are there?

Gartner estimated roughly 2 million COBOL programmers globally in 2004, but nobody has re-counted at that scale since. In the US, the current workforce is approximately 24,000. The average age is 58, per the Teplitzky study of mainframe professionals. About 10% retire each year, and an estimated 30 to 40 percent of the 2019 workforce will have retired or be retiring by end of 2026. The pipeline is limited: IBM's Z Academic Initiative covers 120-plus schools, and the Master the Mainframe program graduated 4,286 students, but annual throughput cannot match the retirement rate.

What salary should I expect to pay COBOL developers?

Average COBOL developer salaries in the US range from $105,000 to $125,000 per year. Senior developers with deep mainframe expertise (CICS, DB2, IMS, z/OS internals) command $155,000 to $188,000, and salaries are rising 10 to 15 percent annually due to supply constraints. Contract rates run $50 to $83 per hour. The most valuable profile, a "bilingual" developer who understands both COBOL/mainframe and modern stacks like Java and cloud, commands a significant premium above these ranges because they can bridge legacy systems and modernization efforts.

Is COBOL really still used?

Yes. COBOL processes an estimated $3 trillion in daily commerce, runs 95% of ATM transactions (per IBM and Reuters, sourced from a 1997 Gartner survey of 421 companies), and powers 43% of US banking core systems. Five billion new lines of COBOL are added per year. JPMorgan Chase, Bank of America, Citigroup, Wells Fargo, HSBC, Visa, the IRS, and the Social Security Administration all run critical infrastructure on COBOL. IBM, the US government, and the financial services industry treat COBOL as active production infrastructure, not legacy technology.

How long does it take to hire a COBOL developer?

Time-to-fill once you identify a qualified candidate averages 36 to 42 days (per Zippia), but reaching full productivity on complex mainframe environments takes 1 to 2 years. The real bottleneck is finding qualified candidates at all. With roughly 24,000 COBOL developers in the US, an average age of 58, and 84,000 unfilled mainframe positions projected, the sourcing phase is where most hiring timelines break down, not the interview pipeline.

Should I hire experienced COBOL developers or train new ones?

Both, at the same time. For maintenance of critical production systems (batch processing, CICS online transactions, JCL job scheduling), experienced developers are necessary because ramp-up takes 1 to 2 years on complex mainframe environments. For modernization projects (COBOL-to-Java migration, cloud integration, API wrapping), developers who know modern stacks and can learn COBOL through IBM's training programs are an emerging pipeline. Many organizations run both tracks: experienced developers keep production stable while newer developers work on modernization under senior mentorship.

What is the COBOL developer shortage actually caused by?

Three factors that are all hitting at once. The average COBOL developer is 58 years old, with roughly 10% of the workforce retiring each year. An estimated 30 to 40 percent of the 2019 workforce will have retired by end of 2026. Almost no universities teach COBOL in their standard CS curricula; IBM's Z Academic Initiative covers 120-plus schools, but throughput is a fraction of what is needed to replace retirees. And younger developers see mainframe work as unglamorous despite competitive salaries ($105,000 to $188,000), creating a cultural barrier to entry. IBM's academic partnerships and the Open Mainframe Project are the main countermeasures, but they cannot match the retirement rate.