stack-swap-simulator

name	stack-swap-simulator
description	Estimates cost and effort to switch from one tech stack to another

Stack Swap Simulator Skill

Estimates cost and effort to switch from one tech stack to another. Helps answer: "Can we migrate later if needed?"

When to Use

Use this skill to understand:

1. Cost of switching stacks — engineer weeks + downtime risk
2. Timeline to switch — how long is the project?
3. Risk of switching — what can go wrong?
4. ROI of switching — does it save money long-term?
5. Backwards compatibility — can we do a gradual migration?

Input

Provide source and target stacks:

{
  "from_stack": {
    "backend": "Node.js",
    "database": "MongoDB",
    "deployment": "Vercel"
  },
  "to_stack": {
    "backend": "Go",
    "database": "PostgreSQL",
    "deployment": "Kubernetes"
  },
  "codebase_size": 50000,  // lines of code
  "monthly_revenue": 50000,
  "max_downtime_hours": 4
}

Output

A migration impact report:

{
  "from": "Node.js + MongoDB + Vercel",
  "to": "Go + PostgreSQL + Kubernetes",
  "feasibility": {
    "effort_engineer_weeks": 8,
    "cost_dollars": 50000,
    "timeline_weeks": 10,
    "downtime_hours": 4,
    "risk_level": "high"
  },
  "cost_breakdown": {
    "engineering_salaries": 40000,  // 8 weeks × 4 engineers
    "infrastructure_setup": 3000,    // Kubernetes cluster setup
    "testing_and_qa": 2000,         // Migration testing
    "consulting_fees": 5000         // Go/Kubernetes specialists
  
   
     
     
     
     
     
  
     
   
       
     
       
  
   
          
           
      
      
  
   
    
    
    
    
    
  
   
   
    
    
    
    
    
    
  
   

Migration Scenarios

Scenario 1: Easy Migration (Same database, swap backend framework)

Example: Node.js → Go (both use PostgreSQL)

Effort: 2-3 engineer weeks
Cost: $10-15k
Downtime: 1-2 hours
Complexity: Low (database schema unchanged)

Steps:

1. Build Go version of API (reuse same database)
2. Run both systems pointing to same database
3. Route traffic gradually (5% → 25% → 100% to Go)
4. Retire Node.js once stable

Why easy: Database contract unchanged, can run both simultaneously

---

Scenario 2: Medium Migration (Swap backend AND database)

Example: Node.js + MongoDB → Go + PostgreSQL

Effort: 6-8 engineer weeks
Cost: $40-50k
Downtime: 2-4 hours
Complexity: Medium (schema mapping needed)

Steps:

1. Build PostgreSQL schema (map MongoDB documents → tables)
2. Implement data migration script (background job)
3. Build Go API against PostgreSQL
4. Run both systems for parallel testing (1-2 weeks)
5. Final cutover (stop MongoDB writes, run Go only)

Why harder: Must map MongoDB doc structure → PostgreSQL schema (not 1-to-1)

---

Scenario 3: Hard Migration (Swap backend, database, AND deployment)

Example: Node.js + MongoDB + Vercel → Go + PostgreSQL + Kubernetes

Effort: 8-12 engineer weeks
Cost: $50-80k
Downtime: 4-8 hours
Complexity: High (infrastructure completely different)

Steps:

1. Set up Kubernetes cluster (AWS EKS, GCP GKE, etc.)
2. Build data migration pipeline (MongoDB → PostgreSQL)
3. Build Go API
4. Set up Kubernetes deployments, monitoring, logging
5. Test extensively (Kubernetes failure modes different)
6. Cutover with careful monitoring

Why hard: Three different systems, all must work together correctly

---

Scenario 4: Impossible Migration (Too risky)

When NOT to migrate:

• System in active development (too much flux)
• No downtime tolerance (24/7 uptime required)
• Complex stateful logic in old system
• Small team (can't afford to stop feature development)

Example: Live multiplayer game (can't take 4 hours downtime)

---

Cost Analysis: When Does Migration Pay Off?

Formula:

migration_cost = engineering + infrastructure + consulting + opportunity_cost

annual_savings = current_cost - new_cost

payback_period_months = migration_cost / (annual_savings / 12)

worth_it = payback_period <= 18 months (typical 3-5 year horizon)

Example:

Current: Node.js + Vercel = $8k/month
New: Go + Kubernetes = $4k/month
Savings: $4k/month = $48k/year

Migration cost: $50k
Payback period: 50k / (48k/12) = 12.5 months ✅ Worth it

Running payoff calculation:
  Month 0: -$50k (migration)
  Month 12: -$50k + (4k × 12) = -$2k (still not paid back)
  Month 13: -$50k + (4k × 13) = +$2k ✅ (now profitable)

---

Risk Assessment

Data Loss Risk

High risk (10-20%):

• Complex data transformations (high chance of bug)
• No test environment matching production
• One-shot migration (can't rollback)

Medium risk (3-5%):

• Simple schema mapping (low chance of bug)
• Good test environment
• Parallel running period (can verify data)

Low risk (<2%):

• Straight replication (MongoDB → JSON in PostgreSQL)
• Extensive testing
• Easy rollback plan

Mitigation: Run both systems simultaneously for 1-2 weeks, verify data matches exactly

---

Downtime Risk

Factors:

• Can you run both systems in parallel? (Reduces downtime)
• How complex is data cutover? (Simple = fast, complex = slow)
• Have you tested the cutover process? (Untested = risky)

Typical downtime estimates:

Simple backend swap: 1 hour
Backend + database: 2-4 hours
Everything including infra: 4-8 hours

Mitigation:

• Cutover during low-traffic window (3am Sunday)
• Have rollback plan ready (can revert to old system)
• On-call engineer present during cutover
• Comprehensive monitoring alerts

---

Budget Overrun Risk

Common reasons for overruns:

1. Data transformation more complex than expected (+20%)
2. Kubernetes learning curve for team (+30%)
3. Production issues discovered during testing (+25%)
4. Scope creep (migrations attract "while we're at it" requests) (+50%)

Strategies to control:

• Fixed-scope contract (define exact features to migrate)
• Weekly cost reviews (catch overruns early)
• Dedicated project manager (enforces timeline)
• Allocate 20% buffer (scope creep reserve)

---

Timeline Overrun Risk

Most migrations take 20-50% longer than estimated:

• Reason 1: Underestimating test time (always takes longer)
• Reason 2: Unforeseen data issues (real data messier than expected)
• Reason 3: Team knowledge gaps (learning curve adds weeks)

Realistic timeline:

• Optimistic estimate: 8 weeks
• Realistic estimate: 8 × 1.3 = 10-11 weeks
• Pessimistic estimate: 8 × 1.5 = 12-13 weeks

Buffer to build in: 2-3 weeks (20-30%)

---

Gradual Migration vs. Big Bang

Big Bang Migration

One day, flip switch from old to new system

Pros:

• ✅ Clean break (one dramatic moment, then done)
• ✅ Easy to understand timeline
• ✅ Forces team commitment

Cons:

• ❌ High risk (if something breaks, users affected immediately)
• ❌ Hard to rollback (both systems running for month = expensive)
• ❌ All eggs in one basket

Risk level: High

---

Gradual Migration

Start routing percentage of traffic to new system, increase over time

Pros:

• ✅ Lower risk (catch issues on 5% traffic before 100%)
• ✅ Easy to rollback (keep old system, just reduce traffic)
• ✅ Real-world testing (production traffic reveals issues labs miss)

Cons:

• ❌ Run both systems longer (more expensive)
• ❌ Complex to coordinate (feature parity needed)
• ❌ Longer timeline (more weeks of dual operation)

Risk level: Medium

---

Decision Tree: Should We Migrate?

1. Is the migration forced?
   a) Yes (old tech no longer supported): DO IT
   b) No (voluntary): go to step 2

2. How much will we save annually?
   a) <$10k/year: Don't migrate (not worth effort)
   b) $10-50k/year: Marginal (do if team capacity allows)
   c) $50k+/year: Worth investigating

3. What's the payback period?
   a) <12 months: ✅ DO IT (quick ROI)
   b) 12-24 months: ⚠️ MAYBE (reasonable if business stable)
   c) >24 months: ❌ DON'T (too long to justify)

4. Do we have team capacity?
   a) Dedicated team (can pause feature work): ✅ Good
   b) Shared capacity (features paused 2 months): ⚠️ Okay
   c) No capacity (features continue): ❌ Too risky

5. Can we do gradual migration?
   a) Yes (architecture supports parallel): ✅ Much safer
   b) No (big bang required): ⚠️ Higher risk

→ Decision:
   Forced migration OR (savings > $50k AND payback < 18 months AND team capacity available)
   → DO IT

   Anything else: Wait (improve ROI or find different problem to solve)

---

Real-World Migration Examples

Example 1: Dropbox (2010-2012)

From: Python → Python + Rust (for file syncing)
Cost: Estimated $5-10M over 2 years
Payoff: 40% reduction in sync latency, better battery life
ROI: Millions per month (core product improvement)
Lesson: Strategic migrations (improve product) have higher ROI than cost migrations

---

Example 2: Heroku to AWS

From: Heroku (managed) → AWS (self-managed)
Cost: $100k over 3 months (migration + consulting)
Savings: $500k/year (self-managing cheaper than Heroku premium)
Payback: 2.4 months ✅ (very quick ROI)
Timeline: 3 months (longer than estimated due to DevOps learning curve)
Lesson: Migrations from expensive managed → cheap self-managed always worth it

---

Example 3: Company Still Running Python 2.7 (2023)

Problem: Python 2 end-of-life (no security patches)
Migration to: Python 3
Status: Still not done! (4 years overdue)
Cost: Estimated $1-2M to do now (would have been $100k in 2018)
Lesson: Don't delay forced migrations (cost grows exponentially)

---

Usage in Commands

In /architect:recommend-stack

// After recommending Go option:
if user_concerned_about_switching_later:
  simulate_swap("Node.js", "Go")
  show: "If you scale to 1M DAU and want Go, it costs $50k and 10 weeks"
  help user: "Is Node.js cheaper for your growth path?"

In /architect:blueprint-variants

// For each variant:
if switching_cost_significant:
  add_to_report: "Switching from baseline to this option later costs $X"
  help_user: "Choose baseline now to keep switching options open"

New command: /architect:simulate-migration

/architect:simulate-migration --from node --to go
→ Estimates cost, timeline, risk, ROI of migration

Related Skills

• constraint-solver/ — picks initial stack (reduces need to migrate)
• stack-compatibility/ — helps pick compatible stacks (easier to migrate between)
• cost-optimizer/ — estimates long-term costs (drives migration decisions)