Case Study 36.2: CNB's Git Migration from SCLM — When 2,000 Programs Change Homes

Background

City National Bank's mainframe development team had used SCLM (Software Configuration and Library Manager) for source management since 1993. In that time, SCLM had accumulated 2,147 COBOL programs, 648 copybooks, 312 BMS maps, 289 JCL procedures, and 167 DB2 DDL scripts — a total of 3,563 source members representing over thirty years of the bank's transaction processing, account management, reporting, and regulatory compliance systems.

Kwame Williams, the VP of Core Banking Technology, had been aware of SCLM's limitations for years. No branching. No merging. Lock-based concurrency that serialized development. No integration with modern development tools. IBM's diminishing investment in SCLM was the final catalyst — Kwame couldn't build a modernization strategy on a tool that IBM itself was moving away from.

"SCLM served us well for thirty years," Kwame told his team. "It doesn't owe us anything. But it can't take us where we need to go."

The Challenge

CNB's SCLM migration was more complex than most because of four factors:

Factor 1: Regulatory Scrutiny. As a federally chartered bank, CNB's source management practices were subject to OCC (Office of the Comptroller of the Currency) examination. The examiners expected to see change history, approval records, and promotion audit trails. Any migration had to preserve these or provide equivalent capability.

Factor 2: Active Development. CNB couldn't freeze development for the migration. At any given time, 15-20 changes were in various stages of the SCLM pipeline (development, test, staging, production). The migration had to handle in-flight changes without disrupting them.

Factor 3: SCLM-Specific Metadata. SCLM stored metadata beyond source code: change authorization records, promotion history, component relationships, and build dependency information. Some of this metadata was required for regulatory compliance.

Factor 4: Team Demographics. CNB's 23-person mainframe team ranged from Rob Chen (57, SCLM power user since 1994) to Marcus Kim (26, two years out of college, never seen SCLM). The migration needed to work for both.

The Plan

Lisa Park, who Kwame appointed as migration lead, developed a detailed plan with input from the entire team.

Phase 1: Preparation (Weeks 1-6)

Week 1-2: Infrastructure Setup Lisa established the Git infrastructure: a GitLab instance on CNB's internal cloud, configured with LDAP integration for authentication. She created the repository structure following the pattern from Section 36.2, adapted for CNB's organizational conventions:

cnb-core-banking/
├── src/
│   ├── cobol/
│   │   ├── online/           # CICS programs
│   │   ├── batch/            # Batch programs
│   │   └── subpgm/           # Shared subprograms
│   ├── copybook/
│   │   ├── data/             # Data structure copybooks
│   │   ├── screen/           # BMS-related copybooks
│   │   └── common/           # Shared utility copybooks
│   ├── bms/
│   ├── jcl/
│   │   ├── compile/
│   │   ├── batch/
│   │   └── utility/
│   └── sql/
│       ├── ddl/
│       ├── dml/
│       └── procedures/
├── test/
│   ├── unit/
│   ├── integration/
│   └── data/
├── config/
├── docs/
│   └── migration/            # Migration tracking
├── .gitattributes
├── .gitignore
├── Jenkinsfile
└── README.md

Week 3-4: Baseline Export Lisa wrote a REXX exec that exported every SCLM member to USS files, preserving the source code, the last-change date, and the last-change user ID. The export ran overnight and produced 3,563 files totaling 247 MB of source.

The critical decision: should the Git history start fresh (one commit with the current state) or should they attempt to reconstruct history from SCLM's change records?

Lisa chose a pragmatic middle ground. The initial commit contained the current production source with a commit message documenting the SCLM migration date. SCLM's historical change records were exported to a separate archive (a PDF-rendered report) for regulatory compliance, but not imported into Git history. Attempting to reconstruct thirty years of SCLM history as Git commits would have taken months and produced a misleading history (SCLM's change granularity was different from Git's).

"Perfect is the enemy of done," Lisa said. "We preserved the SCLM history for auditors and started fresh in Git. Our auditors agreed this was acceptable as long as we could produce the old history on demand."

Week 5-6: Training Every developer completed a two-day Git training course taught by Lisa and Marcus Kim (who, as the youngest team member, was already fluent in Git from his university coursework and personal projects). The training used CNB's actual COBOL source — not generic examples — so developers practiced with code they recognized.

The training covered: basic Git operations (clone, add, commit, push, pull), branching and merging, pull requests and code review, conflict resolution, and the .gitattributes encoding handling.

Rob Chen, the senior-most developer, attended with visible reluctance. By the end of day two, he had successfully created a feature branch, made a change to a copybook, submitted a pull request, and resolved a merge conflict. "It's not as hard as I expected," he admitted. "But I still miss the simplicity of SCLM's lock model." Lisa anticipated this: "The lock model prevented conflicts by preventing concurrent work. Git prevents conflicts by resolving them intelligently. It's a different philosophy, and it takes some getting used to."

Phase 2: Parallel Operation (Weeks 7-18)

For twelve weeks, both SCLM and Git operated simultaneously. The rule was: all changes must go into Git, and SCLM remains the system of record for production promotion.

Lisa set up a synchronization process:

Direction 1: Git -> SCLM (developer-initiated) When a developer completed a change in Git and it was merged to the develop branch, they also applied the change to SCLM for production promotion through the existing change management process.

Direction 2: SCLM -> Git (automated nightly) A nightly job compared the SCLM production library to the Git main branch and reported any discrepancies. This caught cases where a developer updated SCLM but forgot to commit to Git, or where an emergency fix was applied directly to SCLM.

The parallel operation was the most painful phase. Developers were effectively maintaining two systems, and the dual-write requirement slowed them down. But Lisa tracked the discrepancy reports and used them to identify developers who needed additional Git support:

Phase 3: Cutover (Weeks 19-20)

The cutover was scheduled for a weekend with no planned deployments. The process:

Friday evening: 1. Freeze all SCLM changes (no new promotions) 2. Final SCLM -> Git synchronization and verification 3. Verify every SCLM production member matches Git main branch

Saturday: 4. Reconfigure the CI/CD pipeline (built during parallel operation) to be the primary build path 5. Run a full build from Git through the pipeline to verify all programs compile 6. Run the regression test suite to verify the built programs function correctly

Sunday: 7. Final verification 8. Communication to the team: "Git is now the system of record" 9. SCLM set to read-only mode

The cutover proceeded without incident. Every program compiled. Every test passed. On Monday morning, the first pull request was merged in the new workflow, and by Wednesday, the team was operating as if they'd been using Git for years.

Phase 4: Stabilization (Weeks 21-30)

The first ten weeks after cutover required constant attention:

Issue 1: EBCDIC encoding edge cases. Three programs contained non-standard characters in comment lines (box-drawing characters that had been entered from a 3270 terminal in the 1990s). The encoding conversion mangled them. Lisa replaced them with standard dash characters.

Issue 2: Sequence number columns. Several legacy programs had data in columns 73-80 (the traditional sequence number area). SCLM preserved these; Git's .gitattributes configuration stripped them. Two programs actually referenced sequence numbers in their logic (a terrible practice, but it existed). Lisa identified these programs and added a pre-commit hook to preserve columns 73-80 for them.

Issue 3: Copybook case sensitivity. SCLM was case-insensitive for member names; Git on Linux is case-sensitive. A COPY statement referencing 'ACCTMSTR' wouldn't find a file named 'acctmstr.cpy'. Lisa standardized all copybook filenames to uppercase and added a pre-commit hook that rejected lowercase copybook names.

Issue 4: Merge anxiety. In the first month, several developers avoided branching because they were afraid of merge conflicts. When a conflict did occur, they asked Lisa for help rather than resolving it themselves. Lisa addressed this with a "Merge Monday" practice — every Monday, she walked through any conflicts from the previous week with the team, demonstrating resolution techniques. Within a month, developers were resolving conflicts independently.

The Regulatory Question

Three months after the cutover, the OCC examiners arrived for their annual technology examination. Lisa had prepared a comprehensive briefing:

1. Change traceability: Every change was traceable through Git commits and pull requests, with reviewer approval, ticket numbers, and timestamps. This was actually more traceable than SCLM, which only recorded the last change to each member.

2. Historical records: The SCLM historical archive was available in a searchable PDF report for any change prior to the migration date. Post-migration changes were in Git with full history.

3. Separation of duties: Pull requests required approval from a reviewer different from the author. SCLM had a similar requirement, but enforcement was policy-based (manual verification). Git's enforcement was technical (the system rejected merges without required approvals).

4. Audit trail: Every pipeline execution was recorded in Jenkins with artifacts, test results, and deployment records.

The examiner's assessment: "The bank's new source management system provides equal or superior change control to the previous system, with improved traceability and automated enforcement of separation of duties. No findings."

Kwame framed the assessment and hung it on the team room wall.

Outcomes

Quantitative Results (Six Months Post-Migration)

Qualitative Results

Developer satisfaction: Anonymous survey showed 78% of developers preferred Git to SCLM (14% neutral, 8% preferred SCLM). The 8% who preferred SCLM were all developers who worked primarily on individual programs with no concurrency needs — for them, SCLM's simplicity was a genuine advantage.

Knowledge sharing: Pull request code reviews created a knowledge-sharing mechanism that hadn't existed before. Junior developers learned by reviewing senior developers' code. Senior developers caught issues they'd never have seen under the old promote-and-hope model.

Rob's conversion: Six months after the migration, Rob — the team's most experienced developer and initial skeptic — wrote a Git alias that automated his most common workflow (create branch, make changes, submit PR). He shared it with the team. "If I can write Git aliases at 57," he told the team, "you can all learn Git."

Lessons Learned

1. Clean the data before migrating. The encoding issues, sequence number problems, and case sensitivity issues should have been identified and resolved during the preparation phase, not discovered during stabilization.

2. Don't try to import history. Starting fresh in Git with archived SCLM history was the right decision. Attempting to reconstruct thirty years of SCLM history would have delayed the project by months with minimal practical benefit.

3. The parallel operation phase is painful but necessary. The twelve weeks of dual-write were the worst part of the project. But they provided the safety net that made the cutover low-risk and built the muscle memory that made post-cutover operations smooth.

4. Engage the regulators early. Lisa briefed the OCC examination team informally before the migration, explaining the plan and the compliance strategy. This prevented surprises during the formal examination.

5. Pair the youngest and oldest. Marcus (youngest, Git-fluent) and Rob (oldest, COBOL-fluent) became an unexpected partnership. Marcus taught Rob Git; Rob taught Marcus why the old processes existed. Both learned from the exchange, and their partnership became a model for the team.

Discussion Questions

1. Lisa chose to start Git history fresh rather than importing SCLM history. Under what circumstances would importing historical changes be worth the effort? What if a regulatory requirement demanded it?

2. The parallel operation phase had a measurable productivity cost (dual-write overhead). How would you justify this cost to a manager who asks, "Can't we just switch over in one weekend?"

3. Rob's initial resistance and eventual conversion is a common pattern. How would you handle a senior developer who, unlike Rob, refuses to engage with Git after training? At what point does resistance become a performance issue?

4. The OCC examiner found Git's controls "equal or superior" to SCLM's. Are there any compliance scenarios where Git would be inferior to a traditional mainframe source management system? Consider audit requirements in healthcare (HIPAA) or defense (NIST 800-171).

5. CNB migrated 3,563 source members. How would the migration approach change for a larger shop with 20,000+ members across multiple applications? What organizational structure would you need?