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 05 of 10 8-12 weeks· advanced

Step 5: Build the Coexistence Layer

Bridge IBM i and the new system: API gateway, data sync, federated auth, observability that spans both worlds. Easier than mainframe coexistence — IBM i has good ODBC/JDBC drivers and Integrated Web Services.

What you're doing in this step

Stand up an API gateway in front of IBM i (Integrated Web Services exposes RPG as REST). Wire CDC or MQ-based data sync (IBM CDC / Qlik Replicate). Federate auth (Azure AD / Okta with IBM i LDAP). Centralize observability across both. Optionally use Profound UI to web-front 5250 screens during transition.

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 day

Coexistence Architecture ADR

Document the architecture decisions for running legacy and new systems in parallel during migration: routing, auth, data, and sessions.

View template
Template· Template 1 day

Authentication Migration Strategy (.NET Forms Auth → JWT/OAuth)

Migrate from legacy .NET authentication (Forms Auth, Windows Auth, custom) to modern JWT/OAuth without breaking existing users.

Use this when: The auth shim across IBM i user profiles + LDAP + cloud IdP is the hardest piece of coexistence

dotnet
View template
Template· Template 0.5 day

Feature Flag Rollout Strategy for Migrations

Use feature flags to safely route traffic between legacy and new systems during migration with controlled rollout and instant rollback.

Use this when: Routing decisions handled by feature-flag system rather than gateway rules

View template
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

Compatibility Layer Generator Skill

Claude Code skill that generates adapters, shims, and proxies for incremental coexistence between legacy and new systems.

claude-codedotnet
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
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

Azure DevOps MCP for Evoke

Pre-configured Azure DevOps MCP server for Claude Code — work items, repos, PRs, and pipelines from chat.

claude-codemcp
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.

  • API gateway operational, routing to IBM i and the new system
  • Data sync running and monitored (lag, error rate, drift detection)
  • Auth federation working — single sign-in covers both
  • Observability across both systems
  • "Hello world" capability deployed end-to-end through the new system
Common pitfalls

What goes wrong at this step

  • Direct IBM i DB queries from the new app — tempting; produces tight coupling that's hard to break later
  • Sync lag invisible — without monitoring, drift accumulates
  • Auth federation half-done — either fully integrate or accept dual logins; partial integration is the worst case
  • Forgetting to expose CL-orchestrated work — background jobs need orchestration too
← Previous step

Command Palette

Search for a command to run...