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 DB2 for i moves to a modern relational target. DB2 for i is more migration-friendly than VSAM/IMS but has its own quirks (multi-member files, logical-file roles, DDS extensions, CCSID, journaling).

What you're doing in this step

Use db2-for-i-to-relational-mapping per major schema. Decide whether logical files are indexes / views / joins. Handle multi-member files. Map DDS-defined columns (TEXT/COLHDG → comments, CHECK/RANGE → constraints). Plan CCSID / EBCDIC encoding. Pick ETL tooling (AWS DMS for DB2 for i, IBM CDC, Qlik Replicate, JDBC/ODBC ETL). Decide stored-procedure / trigger migration.

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 schema

DB2 for i to Relational Database Mapping

Map DB2 for i schemas (with multi-member files, logical files, journaling, DDS extensions) to a modern relational database — Postgres, SQL Server, or Azure SQL.

ibm-irpgpostgressql
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: You want one document covering the whole-system data movement strategy

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: Some patterns (type mapping, identity → SERIAL, constraint translation) apply to DB2 for i too

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
View playbook
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
View skill
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
View skill
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
View skill
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
View config
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
View config
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 for all major files complete
  • Multi-member file strategies decided
  • Logical file translations classified (index / view / join)
  • DDS extensions handled (TEXT/COLHDG → comments, CHECK/RANGE → constraints)
  • CCSID encoding strategy
  • Journaling / commitment control mapped to target equivalents
  • ETL tool selected and validated on sample data
  • Validation queries written
  • Rollback strategy clear
Common pitfalls

What goes wrong at this step

  • Treating DB2 for i like SQL Server — it's relational, but has IBM i-specific features
  • Missing multi-member files — they surface during migration if not caught upfront
  • Ignoring CCSID — EBCDIC → UTF-8 issues surface as garbled characters days later
  • Treating logical files as indexes universally — some are views, some are joins
  • Underestimating volume — same trap as other migrations
← Previous step

Command Palette

Search for a command to run...