$npx -y skills add vaquarkhan/data-engineering-agent-skills --skill mainframe-modernization-and-data-offloadGuides agents through mainframe data modernization and offload workflows. Use when migrating or exposing data from COBOL, JCL, VSAM, IMS, DB2 for z/OS, or batch-oriented mainframe estates into modern lakes, warehouses, streaming systems, and governed data products.
| 1 | # Mainframe Modernization And Data Offload |
| 2 | |
| 3 | ## Overview |
| 4 | |
| 5 | Use this skill when a modernization effort involves mainframe systems, batch schedules, and legacy data structures rather than only modern ETL tooling. It helps agents design offload, replication, contract mapping, coexistence, reconciliation, and cutover paths for mainframe-origin data. |
| 6 | |
| 7 | ## When to Use |
| 8 | |
| 9 | - modernizing `COBOL`, `JCL`, `VSAM`, `IMS`, or `DB2 for z/OS` data flows |
| 10 | - offloading mainframe data to lakes, warehouses, or downstream APIs |
| 11 | - mapping copybooks and legacy record layouts into modern contracts |
| 12 | - designing coexistence between batch mainframe outputs and modern platforms |
| 13 | - planning phased cutover, replay, and reconciliation for legacy estates |
| 14 | |
| 15 | Do not treat mainframe modernization as only a transport problem. Semantics, batch windows, restart behavior, and operational dependencies matter. |
| 16 | |
| 17 | ## Workflow |
| 18 | |
| 19 | 1. Inventory the legacy behavior. |
| 20 | Capture: |
| 21 | - source systems |
| 22 | - copybooks or record layouts |
| 23 | - batch schedules |
| 24 | - restart and rerun behavior |
| 25 | - downstream consumers |
| 26 | |
| 27 | 2. Define the modernization target. |
| 28 | Decide: |
| 29 | - offload versus replication versus coexistence |
| 30 | - target storage and serving platforms |
| 31 | - contract and schema mapping |
| 32 | - latency and batch-window expectations |
| 33 | |
| 34 | 3. Design parity and reconciliation. |
| 35 | Require: |
| 36 | - source-to-target field mapping |
| 37 | - control totals and reconciliation |
| 38 | - correction and replay behavior |
| 39 | - cutover acceptance criteria |
| 40 | |
| 41 | 4. Plan coexistence and cutover. |
| 42 | Cover: |
| 43 | - dual-run period |
| 44 | - dependent consumer migrations |
| 45 | - backout plan |
| 46 | - ownership and incident routing during cutover |
| 47 | |
| 48 | 5. Validate operational readiness. |
| 49 | Check restart, failure recovery, performance windows, and support responsibilities before moving critical consumers. |
| 50 | |
| 51 | ## Common Rationalizations |
| 52 | |
| 53 | | Rationalization | Reality | |
| 54 | | --- | --- | |
| 55 | | "We only need to copy the files out." | Mainframe jobs often encode business rules, restart behavior, and sequencing that must be preserved or redesigned. | |
| 56 | | "Schema mapping is straightforward once we read the copybook." | Field semantics, packed decimals, dates, and code tables often require careful domain translation. | |
| 57 | | "We can switch consumers after one successful run." | Mainframe modernization usually needs parity evidence and a deliberate coexistence period. | |
| 58 | |
| 59 | ## Red Flags |
| 60 | |
| 61 | - copybook or record semantics are not mapped explicitly |
| 62 | - restart and batch-window behavior are ignored |
| 63 | - reconciliation relies on spot checks instead of control evidence |
| 64 | - consumer cutover sequencing is vague |
| 65 | - there is no backout or coexistence plan |
| 66 | |
| 67 | ## Verification |
| 68 | |
| 69 | - [ ] Legacy source behavior and dependencies are inventoried |
| 70 | - [ ] Target contracts and platform boundaries are explicit |
| 71 | - [ ] Reconciliation and parity evidence are designed before cutover |
| 72 | - [ ] Coexistence and backout behavior are documented |
| 73 | - [ ] Operational support and failure recovery are clear |