Step 3: Plan the Strangler Fig Sequence

Slice the migration into independently shippable chunks and decide the order. Slice 1 should be foundational, not the most valuable feature.

What you're doing in this step

Identify each migration slice as a complete user-facing capability (not a layer), define its rollback path, and sequence them so slice 1 builds the coexistence infrastructure rather than chasing user value first.

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

Strangler Fig Migration Plan

Plan an incremental migration where new code gradually replaces legacy, with both running in parallel during the transition.

View template

Template· Template 4 hours

Migration Risk Register

Comprehensive risk inventory for migration projects with likelihood, impact, mitigations, and triggers.

Use this when: You want a separate risk-tracking artifact alongside the slice plan

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

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

Slice list at /docs/migration/slices.md
Each slice is independently shippable and independently rollback-able
Sequence has rationale (why slice 1 is first)
Slice 1 has a detailed plan
Decommissioning criteria documented per slice
Risk register created and reviewed by the team

Common pitfalls

What goes wrong at this step

Slicing by layer — "migrate the database" is wrong. Migrate by capability (sign-in, orders, etc.) end-to-end
Starting with the most valuable feature — slice 1 should be foundational, not impressive
Slices too big — if it's more than 4 weeks of work, split it
Slices too small — if it's less than 1 week, fold it into another slice

← Previous step