Playbook
0 / 10 complete0%
  1. 01
  2. 02
  3. 03
  4. 04
  5. 05
  6. 06
  7. 07
  8. 08
  9. 09
  10. 10
Step 04 of 10 8-12 weeks· advanced

Step 4: Data Migration Design

Plan how data moves from mainframe storage (DB2 z/OS, VSAM, IMS, IDMS, flat files) to a modern relational target. Schema design and ETL strategy.

What you're doing in this step

Inventory each data source, design the relational target schema (using vsam-to-relational-mapping for non-relational sources), choose an ETL strategy (big-bang / dual-write / CDC / trickle), pick tooling (IBM Data Replication / Qlik / AWS DMS / IBM CDC / Connect for IMS), and plan validation + rollback. Watch out for EBCDIC encoding, packed/zoned decimal types, and z/OS-specific column types.

Recommended prompts

Use one of these to do the work in your IDE

Open the template to read it in full. Click Copy prompt to grab it (with your stack values pre-filled where they apply) — then paste into Claude Code, Cursor, or wherever you build.

Primary recommendation 1-2 days per major dataset

VSAM / IMS to Relational Database Mapping

Map mainframe data structures (VSAM, IMS, IDMS, flat files) to a normalized relational schema, preserving keys, relationships, and access patterns.

mainframecobolpostgressql
View template
Template· Template 1-2 days

Data Migration Plan

Plan a safe data migration: schema mapping, ETL strategy, dual-write or one-shot, validation, and cutover with rollback.

Use this when: DB2 z/OS → cloud RDBMS migration where the schema is already relational

View template
Template· Template 1 day

SQL Server to Modern Schema Translator

Translate SQL Server schemas to modernized SQL Server (Azure SQL) or Postgres, handling type differences, constraints, and stored procedure migration.

Use this when: Adapting the SQL Server translation patterns for DB2 z/OS specifics

postgressql
View template
Playbook· Playbook 1-2 quarters

Database Migration Playbook (Cross-Engine)

Migrate a database between engines (SQL Server → Azure SQL or Postgres) with zero or minimal downtime, parity validation, and instant rollback.

Use this when: The data layer is complex enough to follow its own dedicated playbook in parallel

sqlpostgres
Recommended skills

Drop these into Claude Code for this phase

Skills auto-trigger on the right kind of request. Install once; they apply to every prompt that fits.

Skill· Skill 5 min setup

Data Validation Skill

Claude Code skill that compares old and new system outputs for parity — running validation queries on both DBs and reporting drift.

claude-codesql
Skill· Skill 5 min setup

Migration Planner Skill

Flagship migration skill that walks Claude Code through audit → strategy → slicing → cutover for any legacy system migration.

claude-code
Skill· Skill 5 min setup

Database Migration Skill

Claude Code skill that generates safe forward and reverse migrations with transaction-wrapping, idempotency, and zero-downtime patterns.

claude-code
Recommended MCP configs

Wire these tools into Claude Code first

MCP servers give Claude Code direct access to external systems (Jira, browsers, databases). Configure once.

MCP config· MCP config 10 min setup

Postgres MCP for Evoke

Pre-configured Postgres MCP server for Claude Code — schema inspection and read-only queries to make database work safer and faster.

claude-codemcppostgres
MCP config· MCP config 5 min setup

Filesystem MCP for Evoke

Pre-configured filesystem MCP server for Claude Code — safe, scoped read/write access to project files.

claude-codemcp
When you're done

Verify these in your own work before moving on

This is a checklist for you to mentally tick off in your repo and IDE — the site doesn't track it, you do.

  • Schema mapping complete for all major datasets
  • ETL strategy chosen (big-bang / dual-write / CDC / trickle)
  • Tooling chosen and validated on sample data
  • Encoding strategy documented (EBCDIC → UTF-8)
  • Sign / decimal conventions handled (packed / zoned decimal)
  • Validation queries written
  • Rollback strategy clear (preserve source until well after cutover)
Common pitfalls

What goes wrong at this step

  • Trying to "improve" the schema during migration — migrate as-is; clean up later. Two changes at once are two bugs at once
  • Ignoring EBCDIC encoding — surfaces as garbled characters days later
  • Underestimating volume — "it's only a few terabytes" is a few terabytes you have to validate
  • Skipping spot-checks — counts and sums match while specific records can still be wrong
← Previous step

Command Palette

Search for a command to run...