Agent skill
strangler-fig
Incremental migration from legacy systems. Run old and new in parallel, gradually shift traffic, rollback at any point. Zero downtime, production-validated.
Install this agent skill to your Project
npx add-skill https://github.com/adaptive-enforcement-lab/claude-skills/tree/main/plugins/patterns/skills/strangler-fig
SKILL.md
Strangler Fig
When to Use This Skill
Use when:
- Replacing critical production systems
- High risk of downtime
- Need gradual validation
- Rollback must be instant
Don't use when:
- Small, non-critical systems (just replace)
- No production traffic yet
- Resource cost of running both systems is prohibitive
Implementation
Traffic Routing Approach
- Implementation Strategies - Feature flags, parallel run validation, database migration strategies
- Traffic Routing - Percentage-based, user-based, and canary deployment patterns
- Monitoring and Rollback - Track both systems, compare metrics, instant rollback
Component Replacement Approach
- Platform Component Replacement - Build-replace-remove pattern for infrastructure, zero downtime component swaps
Migration Process
- Migration Guide - Eight-phase checklist, common pitfalls, real-world timeline
Techniques
Two Approaches to Strangler Fig
The strangler fig pattern has two distinct implementation approaches depending on what you're replacing:
Approach 1: Traffic Routing (User-Facing Systems)
Gradually shift user traffic from old to new system using percentage-based routing.
Use for:
- API migrations (REST v1 → v2)
- Feature rollouts (old checkout → new checkout)
- UI rewrites (legacy frontend → modern frontend)
- Application logic changes
How it works: Router/proxy directs percentage of traffic to new system. Start at 1%, increase gradually to 100%.
Approach 2: Component Replacement (Infrastructure)
Replace entire components without routing traffic, including databases, service meshes, operators, and storage.
Use for:
- Database migrations (single instance → HA cluster)
- Service mesh replacement (Linkerd → Istio)
- Operator upgrades (CRD v1alpha1 → v1)
- Storage backend changes (EBS → EFS)
How it works: Build new component, ensure compatibility, swap references, remove old component. No routing layer needed.
Key distinction: Traffic routing = gradual user migration. Component replacement = infrastructure swap with compatibility layer.
Examples
See examples.md for code examples.
Related Patterns
- Separation of Concerns
- Graceful Degradation
- Environment Progression
References
Recommended Agent Skills
Expand your agent's capabilities with these related and highly-rated skills.
adaptive-enforcement-lab/claude-skills
github-token-permissions-overview
Understanding GITHUB_TOKEN scope, default permissions, and implementing least-privilege principle for GitHub Actions workflows.
adaptive-enforcement-lab/claude-skills
secure
Find and fix security issues before they become incidents. Vulnerability scanning, SBOM generation, supply chain security, and secure authentication workflows.
adaptive-enforcement-lab/claude-skills
complete-workflow-examples
Copy-paste hardened CI/CD workflows with SHA-pinned actions, minimal GITHUB_TOKEN permissions, OIDC authentication, and comprehensive security scanning for GitHub Actions.
adaptive-enforcement-lab/claude-skills
ephemeral-runner-patterns
Disposable runner patterns for GitHub Actions. Container-based, VM-based, and ARC deployment strategies with complete state isolation between jobs.
adaptive-enforcement-lab/claude-skills
action-pinning-overview
Why pinning GitHub Actions to SHA-256 commits matters for supply chain security. Attack vectors from unpinned actions and comparison of tag vs SHA pinning.
adaptive-enforcement-lab/claude-skills
github-actions-security-patterns-hub
Complete security patterns for GitHub Actions covering action pinning, GITHUB_TOKEN permissions, third-party action risks, secret management, and runner security.
Didn't find tool you were looking for?