COBOL still runs an estimated 95% of ATM transactions and 80% of in-person transactions worldwide - yet most modernization programs stall not from lack of understanding, but lack of prioritization. The right approach is to score your COBOL estate systematically and move through it in deliberate waves, tackling components where business value is highest, risk is greatest, and migration is realistically achievable.

Step 1: Inventory and group components

Create an application inventory at the "component" level, not just systems. For each COBOL component (program, batch job group, sub-system), capture at least:

• Business capability it supports (payments, claims, pricing, GL, etc.)
• Upstream/downstream dependencies (files, DBs, MQ, APIs, copybooks)
• Operational profile (batch/online, schedule, peak volumes, SLAs)
• Technology characteristics (LOC, cyclomatic complexity, copybook reuse, custom VSAM layouts)

Cluster components into logical domains (e.g., "Customer Master," "Billing," "Reporting") so you prioritize at domain level rather than across hundreds of individual programs.

Step 2: Define a prioritization scorecard

Use a 3-5 factor scorecard with 1-5 scores per factor and compute a weighted total. Common dimensions:

• Business criticality & value: Revenue impact, regulatory exposure, customer experience sensitivity
• Technical risk & fragility: Incident frequency, performance issues, lack of test coverage, obsolete dependencies (CICS versions, VSAM hacks)
• Change velocity: How often requirements change or new features are needed
• Dependency centrality: Is it a hub many others call, or a leaf that mostly consumes?
• Modernization feasibility: Clarity of business rules, SME availability, documentation quality, testability

Example formula:\ Priority score = (0.3 × Business) + (0.25 × Risk) + (0.2 × Change velocity) + (0.15 × Dependency) + (0.1 × Feasibility)

Step 3: Categorize: migrate-first / migrate-later / preserve

Translate score ranges into three buckets to build your roadmap.

• Migrate-first - High business value, high risk/fragility, moderate feasibility. Examples: customer-facing pricing logic, core payments/settlement, compliance reporting.
• Migrate-later - Medium value or low risk, but still on main dependency paths; good candidates after early wins.
• Preserve-as-is - Low change velocity, well-behaved, expensive to touch relative to benefit (e.g., stable historical archives, low-value batch reports).

This triage aligns modernization sequence with business risk appetite and delivery capacity.

Step 4: Prefer decouple -> coexist -> migrate

Avoid "big-bang rewrite"; use incremental patterns. The typical path is:

1. Decouple: Expose stable COBOL functions as APIs or services and introduce integration layers so new services can coexist.
2. Coexist: Run modernized components and COBOL side-by-side, gradually shifting traffic and keeping rollback options.
3. Migrate: Once stable, retire the COBOL component or reduce it to a narrow core.

This lets you target "edge" components where APIs or adapters can be safely inserted without destabilizing the whole mainframe.

Step 5: Pick your "first wave" candidates

Within the migrate-first bucket, filter for good first-wave targets:

• Clear business sponsor and KPIs (latency reduction, error-rate reduction, faster change lead time)
• Well-bounded scope (limited programs and data stores)
• Testability (representative datasets, known expected outputs, ability to parallel-run)
• Reasonable complexity for a 3-6 month tranche, not a multi-year rewrite

Often good first wave: channel integration layers, reporting/analytics feeders, and high-value but well-bounded batch processes where API-enablement delivers visible benefit with moderate risk.

Prioritization matrix guides migration and modernization choices.

You can tune factors and weights to your context - for example, a bank facing a Basel IV deadline might weight "regulatory exposure" at 0.4, immediately surfacing risk and capital calculation components to the top of the queue.

Revisit your scorecard regularly

Prioritization is not a one-time exercise. As your program progresses, the landscape shifts - dependencies dissolve, technical debt accumulates, and business priorities change. Revisit your scorecard at the start of every major planning cycle (typically quarterly) to re-rank remaining components. A component that scored "preserve" today may score "migrate-first" in twelve months if regulatory pressure mounts or a key SME retires.