# Monolith To Serverless

> Use when performing monolith to serverless — guides the decomposition of a monolithic application into serverless functions and managed services. Covers domain boundary identification, function extraction, event-driven architecture design, state management, and incremental migration using the strangler fig pattern.

- Skill: `cloudthinker-ai/monolith-to-serverless` (Agent Skill)
- Install (CLI): `npx skillmds@latest add cloudthinker-ai/monolith-to-serverless`
- Raw SKILL.md: https://api.skillmd.com/api/skills/cloudthinker-ai/monolith-to-serverless/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: cloudthinker-ai (https://skillmd.com/u/cloudthinker-ai)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/cloudthinker-ai/monolith-to-serverless

---


# Monolith to Serverless Migration Plan

## Phase 1: Domain Analysis
1. Map the monolith's bounded contexts
   - [ ] Identify distinct business domains within the application
   - [ ] Document data ownership per domain
   - [ ] Map synchronous and asynchronous communication patterns
   - [ ] Identify shared libraries and cross-cutting concerns
2. Assess each domain for serverless suitability

### Serverless Suitability Matrix

| Domain | Stateless | Event-Driven | Short-Lived | Cold Start OK | Serverless Fit |
|--------|-----------|-------------|-------------|---------------|----------------|
|        | [ ]       | [ ]         | [ ]         | [ ]           | High/Med/Low   |

## Phase 2: Architecture Design
1. Design event-driven architecture with message broker
2. Define API Gateway routes and function mappings
3. Plan state management strategy (database per function vs. shared)
4. Design authentication and authorization flow
5. Plan for cold start mitigation (provisioned concurrency, warm-up)

### Component Mapping

| Monolith Component | Serverless Target | Trigger Type | State Store |
|-------------------|-------------------|-------------|-------------|
|                   | Function/Step Function/Container | HTTP/Event/Schedule | |

## Phase 3: Infrastructure Setup
1. Provision serverless platform and supporting services
2. Set up API Gateway with routing rules
3. Configure event bus or message queue
4. Set up databases per domain (DynamoDB, Firestore, etc.)
5. Implement shared layers/extensions for common code
6. Configure monitoring and distributed tracing

## Phase 4: Incremental Extraction (Strangler Fig)
1. Start with the lowest-risk, most independent domain
2. Extract domain logic into serverless functions
3. Route traffic through API Gateway with fallback to monolith
4. Validate behavior matches monolith
5. Repeat for each domain in priority order

## Phase 5: Data Migration
1. Migrate data from monolith database to domain-specific stores
2. Implement data synchronization during transition period
3. Handle cross-domain queries with aggregation patterns
4. Validate data consistency across services

## Phase 6: Optimization & Finalization
1. Remove extracted code from monolith
2. Optimize function memory and timeout settings
3. Implement cost monitoring per function
4. Set up auto-scaling policies
5. Decommission monolith after all domains extracted

## Counter-Rationalizations

| Shortcut | Counter | Why |
|----------|---------|-----|
| "We can skip some steps for this case" | Adapt the workflow steps, don't skip them | Skipped steps are where incidents and oversights originate |
| "The user seems to already know what to do" | Complete all workflow phases with the user | The workflow catches blind spots that experience alone misses |
| "This is a minor case, full process is overkill" | Scale the process down, don't turn it off | Minor cases become major when unstructured; the process scales, not disappears |
| "I'll fill in the details later" | Complete each section before moving on | Deferred details are forgotten; real-time capture is more accurate |
| "The template output isn't necessary" | Always produce the structured output format | Structured output enables comparison, audit trails, and handoff to other teams |

## Output Format
- **Domain Map**: Bounded contexts with dependencies and data ownership
- **Architecture Diagram**: Serverless target architecture with event flows
- **Function Catalog**: List of all functions with triggers, inputs, outputs
- **Migration Sequence**: Ordered extraction plan with dependencies
- **Cost Projection**: Expected serverless costs vs. current infrastructure

## Action Items
- [ ] Complete domain analysis and boundary identification
- [ ] Design target serverless architecture
- [ ] Extract first domain as proof of concept
- [ ] Validate performance and cost projections
- [ ] Execute remaining domain extractions in priority order
- [ ] Decommission monolith after full migration