# Replatform vs Refactor vs Rearchitect — Decision Matrix (July 2026)

Use inside the broader **6R** map (rehost / replatform / refactor / repurchase / retain / retire). This worksheet only scores the three “change the app” paths.

| Signal | Prefer **replatform** | Prefer **refactor** | Prefer **rearchitect** |
| --- | --- | --- | --- |
| Business value of change | Ops / reliability win | Product velocity for a bounded domain | New product / regulatory rebuild |
| Code change appetite | Near-zero | Targeted modules only | Greenfield or strangler extracts |
| Team capacity (6–12 mo) | Ops + light app | App + platform | Dedicated platform + domain teams |
| Coupling / shared DB | Tolerate temporarily | Split seams you can test | Only if seams already proven |
| Risk tolerance | Low | Medium | High (time + rewrite risk) |
| Mainframe / COBOL | Rehost / Transform assess | Transform-assisted refactor | Rare — only with clear ROI |

## Scorecard (copy per app)

| App | 6R choice | Path (platform / factor / architect) | Why (1 sentence) | Deferred risk |
| --- | --- | --- | --- | --- |
| | | | | |

## Anti-patterns

- Microservices-first without extractable seams → distributed monolith
- “Rearchitect everything” when 70% of value is managed DB + containers
- Strangler without dual-run / contract tests