monolith-to-serverless

name	monolith-to-serverless
enabled	true
description	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.
required_connections	[{"prefix":"cloud-provider","label":"Cloud Provider"}]
config_fields	[{"key":"source_language","label":"Source Application Language","required":true,"placeholder":"e.g., Java, Python, Node.js, .NET"},{"key":"target_serverless_platform","label":"Target Serverless Platform","required":true,"placeholder":"e.g., AWS Lambda, Google Cloud Functions, Azure Functions"},{"key":"current_architecture","label":"Current Architecture Type","required":false,"placeholder":"e.g., MVC monolith, layered architecture"}]
features	["CLOUD_MIGRATION","SERVERLESS","ARCHITECTURE"]

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