- The paper introduces Mono2Sls, a multi-stage pipeline that automates monolith-to-serverless migration using static analysis and specialized LLM agents.
- It demonstrates 100% deployability and nearly perfect API Coverage F1 in benchmarks across six diverse applications, outperforming conventional methods.
- The findings highlight the critical role of explicit architectural planning and AWS-native design in achieving reliable code transformation and deployment.
Mono2Sls: Automated Monolith-to-Serverless Migration via Multi-Stage Pipeline with Static Analysis
Problem Statement and Context
The continued prevalence of monolithic backend architectures in production systems remains a significant source of enterprise technical debt, impeding scalability and cost optimization. Migrating monoliths to serverless architectures on cloud platforms such as AWS is highly desirable, but is non-trivial—requiring decoupling of tightly integrated code, preservation of API contracts and business logic, adoption of distributed data access semantics, and consistent generation of cloud-native Infrastructure-as-Code (IaC) templates. Prior solutions, whether based on static code transformation or LLM-driven repository-level code synthesis, have not adequately addressed these coupled requirements, particularly in maintaining cross-artifact consistency in cloud-specific contexts.
Mono2Sls Pipeline: Architecture and Workflows
Mono2Sls operationalizes a multi-stage migration pipeline mediated by lightweight static analysis and tool-using LLM agents. The pipeline comprises four specialized stages:
- Static Analysis: Extracts HTTP entry points, cross-file call graphs (with async semantics), and DynamoDB schema information from the monolith, outputting analysis_report.json and symbol_table.json for downstream consumption.
- Architect: Utilizes static analysis outputs to generate blueprint.json. This artifact enumerates Lambda boundaries, inter-service communication patterns (synchronous/invoke, async/SQS/EventBridge), infrastructure resources, and authentication strategies. Special handling replaces monolith-based auth endpoints with AWS Cognito, promoting "infrastructure-over-code."
- Code Developer: Reads blueprint.json and applies code transformations—reformatting route handlers to Lambda signatures, replacing custom identity handling with Cognito UUIDs, removing obsolete state, and constructing Lambda Layers for shared utilities. Dependency management is runtime-specific (Python/nodejs) and adheres to AWS best practices.
- SAM Engineer: Translates blueprint.json and generated code into template.yaml, layering resource definitions per dependency hierarchy and validating via cfn-lint. Special logic prevents errors in API Gateway, Cognito, and Lambda Layer references.
- Consistency Validator: Executes 11 cross-artifact checks, covering directory coverage, handler-template alignment, IAM policy correctness, environment variable injection, and async resource wiring. Automatic remediation is followed by re-validation; infinite fix cycles are precluded.
All agent contexts are isolated, communicating via explicit intermediate artifacts rather than global memory, and agents are equipped with domain knowledge bases compiled from AWS documentation to supplement LLM training gaps.
Benchmark Design and Evaluation Protocol
Rigorously evaluating serverless migration tools is challenging due to the paucity of real-world monolith/serverless pairs. Mono2Sls addresses this by reverse-engineering monolithic variants of AWS reference serverless applications, retaining DynamoDB as the primary database and replacing Cognito with JWT-based middleware to generate authentic migration complexity. Six benchmark applications spanning Python and JavaScript, ranging from 601–3,623 LOC and containing 76 business endpoints, are constructed.
Experimental evaluation is performed across four axes:
- Deployability: Success rates for template validation (VPR) and live AWS deployment (DSR), both before and after expert-assisted fixes.
- Functional Correctness: API-coverage F1 (match between generated and reference endpoint sets) and micro-average/macro-average end-to-end test pass rates (E2EPR), covering CRUD, robustness, authentication, and async semantics.
- Contribution of Static Analysis and Architecture Planning: Quantified via ablation studies removing these pipeline stages.
- Cloud-Native Design Adoption: Qualitative architectural analysis of authentication and asynchronous communication patterns.
Baselines include commercial assistants (Cursor, Claude Code) and LLM-Baseline variants (single-context agent setup), with backbone models DeepSeek-V3.2 and Claude Sonnet 4.6 employed to ensure method-driven (not model-driven) results.
Experimental Results and Analysis
Deployability
Mono2Sls attains 100% VPR and DSR on all 6 benchmark applications irrespective of backbone LLM, with no manual fixes, demonstrating robust deployment reliability. Commercial baselines fail validation and deployment on 2–4 of 6 applications, requiring substantial expert-led debugging; LLM-Baseline variants exhibit DSR failures due to subtle handler-template mismatches, underscoring the criticality of staged artifact generation and validation.
Functional Correctness
API Coverage F1 is nearly perfect for Mono2Sls (98.7–100%), with systematic elimination of redundant auth endpoints through Cognito adoption. LLM-Baseline achieves high F1 but fails to bridge the structural-to-functional gap, resulting in only 34% E2EPR. Mono2Sls delivers 66.1% micro-average E2EPR (M2S-Sonnet), outperforming commercial assistants even when evaluated on raw output and without deployment fixes.
Ablation Study: Static Analysis and Architecture Planning
Removal of static analysis and the dedicated Architect agent reduces DSR (6/6 → 3/6), API Coverage F1 (0.987 → 0.915), and E2EPR (66.1% → 38.3% on comparable apps). Pattern failures include miswiring environment variables, API route drift, and Lambda Layer directory errors, confirming the essential role of precomputed structural facts and blueprint-driven resource specification.
Adoption of AWS-Native Patterns
Mono2Sls exclusively employs AWS-native authentication (Cognito + API Gateway authorizer) and reconstructs asynchronous SQS/EventBridge pipelines in all event-driven applications, achieving architectural alignment with serverless best practices. Commercial baselines and LLM-Baseline variants frequently retain monolith-style JWT handling and synchronous flows, or produce hybrid designs due to insufficient separation of architectural concerns.
Practical and Theoretical Implications
Mono2Sls sets a precedent for end-to-end codebase migration using LLMs augmented by static analysis and agent specialization. Practically, the pipeline automates complex migration workflows—decomposition, transformation, and infrastructure generation—lowering cloud adoption barriers for legacy monoliths. Theoretically, it demonstrates the limits of single-context LLM inference in handling architectural tasks requiring cross-artifact coherence and knowledge augmentation.
Empirical results support stronger claims: pipeline architecture dominates backbone LLM choice in effect size, and explicit architectural planning via static analysis and intermediate artifacts is critical for maintaining correctness and deployability. The staged agent approach operationalizes architectural responsibility, mitigating model hallucination and knowledge coverage limitations across rapidly evolving cloud APIs.
Future work should focus on scaling benchmarks to larger industrial monoliths, extending platform support to Azure and GCP, and enhancing LLM reasoning over eventual consistency and distributed semantics in async flows.
Conclusion
Mono2Sls combines static analysis, agent specialization, and AWS-grounded domain knowledge to enable reliable monolith-to-serverless migration. The approach outperforms both commercial and single-context LLM baselines across deployability, correctness, and architectural fidelity, with an ablation confirming the necessity of structural analysis and explicit planning. The pipeline’s limitations reside mainly in benchmark scope and AWS platform specificity, but its methods constitute a robust foundation for broader, more automated cloud migration strategies (2604.24550).