arXiv:2604.24550v1 [cs.SE] 27 Apr 2026
Mono2Sls: Automated Monolith-to-Serverless Migration via Multi-Stage Pipeline with Static Analysis Xingyan Chen
Yuxin Su
Zishan Su
[email protected] Sun Yat-sen University Zhuhai, China
[email protected] Sun Yat-sen University Zhuhai, China
[email protected] The Chinese University of Hong Kong Hong Kong, China
Yang Yu
Zibin Zheng
[email protected] Sun Yat-sen University Zhuhai, China
[email protected] Sun Yat-sen University Zhuhai, China
Abstract Cloud computing platforms offer elastic scaling, managed infrastructure, and pay-per-use pricing, but moving existing monolithic backends to them remains a difficult software engineering task. In practice, the migration requires coordinated changes to program structure, source code, infrastructure configuration, and cloudspecific design decisions, and these changes are still largely carried out by hand. In this paper, we present Mono2Sls, an automated pipeline that converts monolithic web backends into deployable AWS SAM applications. The pipeline combines lightweight static analysis of entry points, call graphs, and asynchronous behavior with four sequential tool-using LLM agents: Architect, Code Developer, SAM Engineer, and Consistency Validator. These agents communicate through explicit intermediate artifacts and consult a curated SAM knowledge base. Evaluated on six benchmark applications totaling more than 10K lines of code and 76 business endpoints, Mono2Sls achieves 100% deployment success without manual fixes. It also reaches 66.1% end-to-end correctness and 98.7% API-coverage F1, whereas the commercial baselines achieve 53.7– 61.2% and 88.4%, respectively. The migrated systems show more consistent use of AWS-native authentication and asynchronous patterns, and an ablation study indicates that static-analysis-guided architecture planning contributes 23.4 percentage points to end-toend correctness.
CCS Concepts • Software and its engineering → Automatic programming.
Keywords serverless migration, multi-stage pipeline, large language models, AWS SAM
1
Introduction
Serverless computing is now widely used for cloud applications because it offers automatic scaling, pay-per-use pricing, and managed infrastructure. Industry reports estimate that the global serverless market will grow from $21.9 billion in 2024 to $44.7 billion by 2029 at a 15.3% compound annual growth rate [18], with 72% of enterprises already running serverless workloads in production [13]. AWS Lambda is central to this ecosystem [4]. At the same time,
much production software still runs as monoliths, and legacy architectures remain a major source of enterprise technical debt [30]. Turning these systems into serverless applications is difficult to automate. An automated migration method must recover decomposition boundaries from tightly coupled code, preserve API contracts and business logic, redesign data access for a distributed runtime, and generate cloud-specific Infrastructure-as-Code (IaC) that remains consistent with the transformed code. Prior studies report recurring problems in testing event-driven systems, integrating legacy infrastructure, and finding reliable migration practices, especially when teams lack serverless experience [19, 35]. These coupled requirements motivate methods that combine program analysis with structured generation. LLMs have shown strong performance on code generation tasks, from function-level synthesis to repository-level modification [21, 24]. Benchmarks such as SWE-Bench [25] and RepoGenesis [29] suggest that commercial assistants such as Cursor and Claude Code can already make substantial repository-scale changes. This progress makes LLMs a natural starting point for migration automation, but existing assistants are not designed to maintain the long-range consistency that serverless migration requires. Decisions about function boundaries, API definitions, handler implementations, and infrastructure declarations must remain aligned across multiple generated artifacts, which is difficult to achieve in a single loosely structured generation context. The difficulty is compounded by rapidly evolving cloud APIs: code LLMs often misuse infrequent APIs [23], and this risk is particularly relevant to AWS SAM, whose configuration space spans more than 800 resource types [36]. Our approach, Mono2Sls, is a multi-stage pipeline for migrating monolithic web backends to AWS SAM applications. It begins by extracting structural facts from the monolith with static analysis and then feeds them into four sequential stages, each handled by a dedicated tool-using LLM agent (Architect, Code Developer, SAM Engineer, Consistency Validator). Together, these stages plan the target architecture, generate Lambda handlers and SAM templates, and verify consistency across artifacts. Decomposing the task in this way lets the system coordinate decomposition, code transformation, and infrastructure generation without forcing all decisions into a single generation context. Our contributions are as follows:
Conference’17, July 2017, Washington, DC, USA
• A multi-stage migration pipeline: A four-stage workflow in which dedicated tool-using LLM agents (Architect, Code Developer, SAM Engineer, Consistency Validator) handle architecture planning, code generation, infrastructure generation, and validation through explicit intermediate artifacts and isolated contexts. • Static-analysis-driven architecture planning: Lightweight analysis that extracts HTTP entry points, cross-file call graphs with async semantics, and DynamoDB schema information to ground migration decisions. • Domain-grounded SAM generation and validation: A curated SAM knowledge base together with a Consistency Validator that performs 11 cross-artifact checks to improve template correctness and deployment readiness. • A benchmark and empirical evaluation: Six web applications reverse-engineered from AWS reference serverless implementations, evaluated for deployability, functional correctness, and cloud-native design adoption.
2 Background and Related Work 2.1 AWS Serverless Architecture Recent reviews of cloud computing identify migration from monolithic systems as an open problem in serverless computing [20, 34]. Empirical studies further show that configuration management and event-driven design are common sources of errors in practice [16, 35]. AWS Serverless Application Model (SAM) [6] is a widely used Infrastructure-as-Code framework for AWS serverless applications. It describes Lambda functions [4], API Gateway, DynamoDB/S3, Cognito [1], and SQS [3]/EventBridge [2] in a YAML template that extends CloudFormation. SAM is expressive, but it is also unforgiving: small mistakes, such as invalid CORS combinations, reserved environment variables, or missing IAM policies, can block deployment. Template correctness is therefore a key requirement for any automated migration system [36].
2.2
LLM-based Code Generation and Migration
LLM-based code generation has progressed from function-level benchmarks (HumanEval [14], MBPP [12]) to repository-level tasks (SWE-Bench [25], RepoGenesis [29]). Static analysis often improves repository-scale performance: STALL+ [28] shows that file-level dependency augmentation outperforms RAG [27] alone, and CodeAgent [37] shows that tool-equipped agents outperform pure-LLM inference at repository scale. For code translation, AlphaTrans [22] decomposes repository-level Java-to-Python translation into reversecall-order fragments with multi-level validation, achieving 96.4% syntactic correctness across ten projects. These systems address peer-language translation, that is, functionally similar implementations in another language. They do not address architectural migration, which requires simultaneously redesigning application structure, replacing the runtime model, and authoring cloud-native IaC declarations.
2.3
Program Migration and Modernization
Microservice decomposition. Wang et al. [33] benchmark eight decomposition tools and find that structural and semantic metrics can yield quite different service boundaries; Romani et al. [31] propose a data-centric identification process for legacy systems;
Author et al.
Kalia et al. [26] use AI-driven runtime call graphs to partition Java monoliths automatically. All three lines of work reason about logical boundaries but stop short of producing deployable infrastructure, so cloud migration remains a manual downstream step. FaaSification. Podilizer [32] and Node2FaaS [15] mechanically extract Java/Node.js methods into Lambda functions via static analysis and code rewriting, without reasoning about architecture, authentication patterns, or asynchronous communication. RADF [38] adds business-logic-aware clustering but still produces blueprints and provisional structures rather than executable Lambda handlers and SAM templates.
3 Approach 3.1 Overview Mono2Sls is a static-analysis-driven multi-stage pipeline that automatically migrates monolithic web applications to AWS SAM applications. As shown in Figure 1, static analysis first produces analysis_report.json, which anchors all downstream LLM reasoning. The pipeline then executes four sequential stages, each powered by a dedicated tool-using LLM agent: the Architect consumes this report and emits blueprint.json, the shared architectural contract for subsequent stages. The Code Developer and SAM Engineer generate Lambda handlers and template.yaml respectively, while the Consistency Validator cross-checks all artifacts, applies fixes, and re-validates. Each agent is equipped with purpose-built tools and a curated domain knowledge base (§3.3); stages communicate exclusively through files, with no direct inter-agent messaging.
3.2
Static Analysis
Before invoking the LLM-based agents, we perform lightweight static analysis to extract structured information that anchors LLM reasoning. The analyzer produces analysis_report.json, which serves as the authoritative input for the Architect agent, and a separate symbol_table.json consumed exclusively by CodeRAGTool for code indexing (§3.3). HTTP Entry Points. For Python, we traverse the AST to detect route decorators (@app.route, @app.get, Flask Blueprint prefix+path aggregation); for JavaScript/TypeScript, we apply regex matching on Express patterns (app.get, router.post, etc.). Each entry point records (method, path, handler_function, file). File Tags. We classify each source file by content features, assigning tags from {AWS_SDK, DynamoDB, Auth, FileUpload}. Tags are detected via keyword matching on the file source (e.g., boto3 imports for AWS_SDK, DynamoDB API calls for DynamoDB, JWT references for Auth). These tags guide the DynamoDB Schema Locator and are available for downstream agent decisions. Cross-file Call Graph with Async Semantics. A two-pass analysis builds a per-file import map (Pass 1) then collects crossfile call edges from function bodies (Pass 2), using AST traversal for Python and regex for JavaScript/TypeScript. Each edge records two semantic flags: return_value_used (false for bare-expression / fire-and-forget calls) and is_awaited. Edges are aggregated per HTTP entry point into a compact dependency map, reducing the Architect’s search from O(𝑛 2 ) to O(1) per endpoint. Figure 2 illustrates this process on a benchmark Flask application: a route
Mono2Sls
Conference’17, July 2017, Washington, DC, USA #5392CE
#94B3DF
#D4DFF1
#75B956
#B3D49B
#E0EFDC
#B266A5
#CDA3CB
#E8DAEB
Multi-Stage Pipeline
Basic Arch
Async Arch
λ Coding
Async Arch
Async λ SAM Arch Coding Ref.
SAM Ref.
Static Analysis PASS Architect
Monolith Repository
Code Developer
SAM Engineer check
guide
JSON
JSON
analysis_report
blueprint
Lambdas/ &layers/
Consistency Validator DeploymentReady AWS SAM Application
template. yaml
Figure 1: Mono2Sls pipeline overview. Static analysis preprocessing produces analysis_report.json, which drives the Architect stage to design blueprint.json. The blueprint then serves as the shared contract for the three downstream stages, namely Code Developer, SAM Engineer, and Consistency Validator, each producing a well-defined output artefact. handler delegating to a cross-file helper is analysed to produce the entry_point_dependencies record in analysis_report.json. DynamoDB Schema Locator. For applications tagged with DynamoDB, we identify schema definition files via a priority heuristic: initialization scripts (e.g., init_db.py, create_tables.js) ≻ database configuration modules (db.py, models.py) ≻ general business logic. The top-3 candidate files are recorded in the report, enabling the SAM Engineer to read exact table schemas rather than inferring them from handler code.
3.3
Agent Tools and Domain Knowledge
Each agent is equipped with a role-specific tool set and a curated subset of the domain knowledge base (Table 1). Tools provide structured, validated interfaces to the file system and external validators, enabling agents to navigate and operate over the entire monolith codebase, while also catching syntactically invalid artifacts before they propagate downstream. Domain knowledge supplements LLM training with up-to-date, task-specific guidance, ensuring generated code and templates follow documented AWS best practices rather than relying solely on the backbone LLM’s training-data coverage of rapidly evolving cloud APIs. File Tools. We implement three file-interaction tools as a group: • ReadFileTool: reads files with optional line-range selection; returns a truncation warning for large files (>500 lines) to prevent context overflow. • WriteFileTool: writes files with built-in syntax validation (Python AST, JSON, YAML); a JSON merge-key mode allows agents to
construct large structured documents section-by-section without exceeding context limits. • FileListTool: lists directory contents with optional recursion, enabling agents to verify that all expected artifacts have been generated. CodeRAGTool. Provides semantic code retrieval over the monolith source. Offline, we build a RAG [27] vector index over source code chunks using CodeBERT [17] (microsoft/codebert-base) embeddings and LlamaIndex, consuming the symbol_table.json produced by static analysis as the chunking reference. At runtime, the tool returns top-𝑘 raw code snippets with relevance scores and file/line metadata. To avoid double inference, the tool operates in retriever-only mode that returns raw snippets without LLM synthesis and leaves all semantic interpretation to the agent’s own inference call. SAMValidateTool. Wraps cfn-lint [7] (AWS CloudFormation Linter) and returns structured feedback distinguishing fatal errors from warnings, enabling an in-task validation–fix loop without leaving the inference context. Domain Knowledge Base. Four reference documents compiled from the AWS SAM and Lambda Developer Guides [6]: (1) Basic Serverless Architecture (resource types, API Gateway, Cognito); (2) Async Patterns (SQS [3]/EventBridge [2] event-source mapping); (3) Lambda Coding Reference (handler signatures, Layer packaging, env-var conventions); (4) SAM Template Reference (valid YAML properties, documented anti-patterns). Each document is chunked and indexed per agent following least-exposure: each agent receives only the knowledge relevant to its task (Table 1).
Conference’17, July 2017, Washington, DC, USA
Input: Monolith Code Snippet
Author et al.
Core Logic: Extraction Algorithms
# airline-booking/app.py (excerpt)
(A) Route / Entry Point Extraction
@app.route('/bookings', methods=['POST']) @login_required
# Pseudocode for each FunctionDef: inspect route decorators extract: - HTTP method (e.g., POST) - path (e.g., /bookings) - handler_function - source file append to entry_points[]
def create_booking(): """Create a new booking""" data = request.get_json() data['customerId'] = request.current_user['sub'] try: # Step 1: Reserve seat CatalogService.reserve_flight_seat( data['outboundFlightId'])
Output: Analysis Report (JSON) # analysis_report.json → entry_point_dependencies[0] (excerpt, 4 of N calls) { "entry_point": { "method": "POST", "path": "/bookings", "file": "airline-booking/app.py" }, "handler_function": "create_booking", "cross_file_calls": [ { "callee_module": "services.catalog", "callee_symbol": "CatalogService.reserve_flight_seat",
(B) Cross-file Call Graph + Async Semantics # Step 2: Reserve booking booking_id = BookingService. reserve_booking(data) # Step 3: Process payment payment_result = PaymentService. collect_payment(data) # Step 4: Confirm booking BookingService.confirm_booking (booking_id) except Exception as e: ... # rollback calls omitted
"return_value_used": false, "is_awaited": false
# Pass 1 – Build Import Map # scan imports in app.py: CatalogService → services.catalog BookingService → services.booking PaymentService → services.payment
}, { "callee_module": "services.booking", "callee_symbol": "BookingService.reserve_booking", "return_value_used": true, "is_awaited": false
# Pass 2 – Walk Function Body for each cross-file call: collect callee_module, callee_symbol annotate return_value_used, is_awaited
}, { "callee_module": "services.payment", "callee_symbol": "PaymentService.collect_payment",
# Semantic Rules bare stmt → return_value_used = false await call → is_awaited = true
"return_value_used": true, "is_awaited": false }, { "callee_module": "services.booking", "callee_symbol": "BookingService.confirm_booking",
(C) Aggregate by Entry Point # Logic Join entry_points with call_edges by (file, handler_function)
"return_value_used": true, "is_awaited": false }
# Result Produce entry_point_dependencies for Architect
] }
Figure 2: Static analysis and dependency extraction workflow. Left: monolith source snippet with annotated cross-file calls. Middle: core extraction algorithms for entry points, call graph, and async semantics. Right: the resulting entry_point_dependencies structure in analysis_report.json. Table 1: Tool and Knowledge Base Assignment per Agent Agent
Tools
Knowledge Bases
Architect
ReadFile, WriteFile
Code Developer
ReadFile, CodeRAG, WriteFile ReadFile, WriteFile, FileList, SAMValidate ReadFile, WriteFile, FileList, SAMValidate
Basic Architecture, Async Patterns Lambda Coding, Async Patterns SAM Template Ref.
SAM Engineer Validator
3.4
SAM Ref., Lambda Coding, Async
Architect
The Architect consumes analysis_report.json and produces blueprint.json, the single source of truth for all downstream agents. The blueprint specifies Lambda function boundaries, interLambda communication patterns, shared infrastructure resources, and the authentication strategy. Its top-level structure is: • lambda_functions: one entry per business endpoint, each recording trigger type, runtime, source files, auth requirement, and async publish targets • dynamodb_tables, s3_buckets, cognito, api_gateway: shared infrastructure specifications • sqs_queues, eventbridge_rules, lambda_invoke_permissions: inter-Lambda communication resources
• dropped_functions: auth endpoints and infrastructure scripts replaced by managed services Static-Analysis-Driven Endpoint Planning. The Architect reads the entry_points array from the report to enumerate all HTTP routes, and consults file_tags to detect auth-related files. Endpoints bearing standard or role-based auth decorators (e.g., @login_required, @warehouse_required, etc.) are classified as auth="required"; auth endpoints (/register, /login, /logout) are dropped entirely and delegated to AWS Cognito, following the “infrastructure-over-code” principle. The remaining business endpoints are mapped one-to-one to Lambda functions (one Lambda per HTTP method+path), providing least-privilege IAM scoping and independent scaling per endpoint. Source-Code-Guided Communication Pattern Selection. Assigning an inter-Lambda communication mechanism is a twophase process. In Phase 1, the Architect uses static analysis hints from entry_point_dependencies: return_value_used=true signals that the caller requires the callee’s result (favouring synchronous invoke), while return_value_used=false combined with is_awaited=false signals a fire-and-forget side-effect (favouring async). However, entry_point_dependencies captures only level1 calls (route handler → service); cross-service calls (service A → service B) are invisible at this level. In Phase 2, the agent therefore autonomously reads the relevant business service source files to trace deeper call chains and resolve ambiguous cases. For each identified cross-domain relationship, the agent applies three rules:
Mono2Sls
Conference’17, July 2017, Washington, DC, USA
(1) Synchronous Lambda Invoke, when the caller needs the callee’s return value to construct its HTTP response; (2) SQS queue, for fireand-forget side-effects with a single consumer; and (3) EventBridge rule, when a single action fans out to two or more independent consumers across different service domains.
appends the Outputs section, and closes with a SAMValidateTool validation loop that iteratively corrects errors before finalisation. Template correctness is critical: a single misconfigured property blocks the entire deployment pipeline, requiring the deep AWSspecific knowledge encoded in the domain knowledge base (§3.3).
3.5
3.7
Code Developer
The Code Developer reads blueprint.json and generates one Lambda handler per lambda_functions entry. For each Lambda, the blueprint provides: the monolith source_files to read, the trigger type and runtime, the auth requirement, async publish targets (publishes_to), and required environment variable names. The agent reads the designated source files first; for implementation details not covered by source_files (helper utilities, shared libraries), it queries CodeRAGTool and follows up with ReadFileTool for full context. Code Transformations. Three key adaptations are applied: (1) Framework adaptation: Flask/Express route handlers are rewritten to the lambda_handler(event, context) signature, extracting path parameters from event[’pathParameters’] and bodies from event[’body’]; (2) Identity model adaptation: the monolith’s integer user_id references are replaced with the Cognito Sub UUID obtained from event[’requestContext’][’authorizer’ ][’claims’][’sub’], and the Users DynamoDB table is removed, and credentials are delegated to Cognito while any business profile fields are retained in a separate table; (3) State elimination: global variables are replaced by environment variables injected at deploy time. Shared Layer and Dependency Management. The agent creates a shared Lambda Layer when utilities are reused across ≥3 Lambdas. Layer content is placed in the runtime-specific path (python/ or nodejs/) required by the AWS Lambda Developer Guide [10], so Lambda mounts it under /opt/. Dependency files are generated only for non-empty filtered dependency sets (stripping pre-bundled runtime packages such as boto3 for Python; helper SDK packages must be explicitly declared for nodejs22.x [8]). All Node.js handlers use CommonJS (require) since Lambda’s /opt/nodejs path is resolved via NODE_PATH, which ESM does not honour. Cross-Lambda Communication. For those Lambdas with publishes_to or lambda_invoke_permissions in the blueprint, the agent injects the corresponding SDK call (e.g., lambda.invoke, sqs.send_message, or events.put_events). Async publishes are awaited before the HTTP response is returned, since Lambda freezes the environment immediately on handler return [9].
3.6
SAM Engineer
The SAM Engineer generates template.yaml from the pre-defined blueprint.json and the generated code via three sequential subtasks following a dependency-based topological layering principle. Sub-task 1 establishes shared stateful resources first (DynamoDB tables, Cognito UserPool, Lambda Layers, API Gateway), creating the CloudFormation logical reference anchors (!Ref, !GetAtt) that downstream definitions resolve. Sub-task 2 processes Lambda function resources domain-by-domain, appending incrementally to ensure referential integrity. Sub-task 3 wires EventBridge rule targets,
Consistency Validator
The Consistency Validator performs cross-artifact verification between Lambda code, SAM template, and blueprint, automatically fixing mismatches to ensure deployment readiness. It executes 11 checks across five phases: (A) Structural: bidirectional directory/function coverage and CodeUri path validity; (B) Code-toTemplate Alignment: handler name validity, environment variable completeness, IAM policy alignment with SDK calls, and sharedlayer reference consistency; (C) Blueprint Matching: API routes or methods matching against blueprint.lambda_functions and per-endpoint auth override correctness; (D) Async Resources: SQS queue existence, producer/consumer policy and env var pairs, EventBridge rule targets and invocation permissions; (E) Runtime Compliance: dependency file correctness (stripping Lambda builtins) and Node.js CJS/ESM enforcement. After all checks, fixes are applied in a single batch and re-validated with SAMValidateTool; anti-loop safeguards prevent infinite cycles.
4
Benchmark
Real-world monolithic applications rarely come with paired serverless counterparts, which makes rigorous evaluation difficult. We therefore adopt a reverse-engineering approach. Starting from AWSmaintained reference serverless applications in aws-samples [5], we examined the top 270 repositories and applied inclusion criteria (SAM-based, HTTP API, no AI/ML dependencies, no proprietary external services). The screening yielded 12 candidates, from which we selected 6 that cover diverse complexity levels and the two dominant Lambda runtimes, Python and JavaScript [11]. For each serverless application, we constructed an equivalent monolith by (1) consolidating Lambda handlers into Flask/Express, (2) retaining DynamoDB for application data to isolate migration complexity from database concerns, (3) replacing Cognito with JWT-based middleware, (4) converting SQS/EventBridge async patterns to synchronous equivalents while preserving detectable async signals for the pipeline to reconstruct, and (5) removing frontend code. We then verified each constructed monolith through E2E testing against the original serverless behavior. The original serverless applications are used only to build the benchmark and identify target cloud-native properties; all migration methods operate exclusively on monolith source code. Table 2 summarizes the benchmark characteristics.
5 Experimental Setup 5.1 Research Questions We evaluate Mono2Sls through four RQs: RQ1 (Deployability) asks whether it can generate deployable applications without manual intervention; RQ2 (Functional Correctness) asks how faithfully it preserves monolith behavior relative to commercial AI assistants and LLM-based generation; RQ3 (Ablation) asks what the contribution of static-analysis-driven architecture planning is; and
Conference’17, July 2017, Washington, DC, USA
Author et al.
Table 2: Benchmark Applications ID
Application
Lang
LoC
EPobs
Tbl
Auth
Async
B1 B2 B3 B4 B5 B6
Todo Shopping Cart Bookstore Coffee Shop Airline Booking E-commerce
JS Py JS JS Py Py
601 1,130 1,349 1,666 2,109 3,623
6 8 11 11 14 26
2 2 4 6 4 6
✓ ✓ ✓ ✓ ✓ ✓
✗ ✗ ✓ ✓ ✓ ✓
–
10,478
76
24
6/6
4/6
Total
EPobs = Observable business endpoints (auth endpoints excluded). Tbl = DynamoDB tables in constructed monolith. Async = monolith contains detectable async patterns (§5.3).
Baseline Migration Prompt You are a senior software engineer specializing in AWS Serverless architecture. Task: Migrate this monolithic web application to AWS SAM-based serverless architecture. Your task: (1) Analyze the application and determine which endpoints to migrate as Lambda functions. (2) Each Lambda function handles one API endpoint. (3) Generate a complete, deployable SAM project. (4) Preserve all original API functionality. (5) Use Node.js 22.x or Python 3.12 runtime. (6) Do not generate any documentation files.
analysis or domain knowledge. All tool-initiated permission requests and confirmation prompts were accepted without redirecting agent decisions. 5.2.2 LLM-Based Baseline. To isolate the effect of staged decomposition, we build an LLM-based baseline (LLM-Baseline) that handles the migration in a single generalist context. It receives the same inputs as Mono2Sls (static analysis, domain knowledge, tool access) but replaces four specialized stages with one generalist agent, collapses seven tasks into two, removes the 11-point consistency validator, and replaces detailed AWS-specific prompts with high-level instructions. Implemented with an agent framework to handle large codebases, it is essentially an end-to-end generation setup without iterative refinement. We evaluate two backbone LLMs, DeepSeek-V3.2 (LLM-Baseline-DS) and Claude Sonnet 4.6 (LLM-Baseline-SN), to keep the comparison controlled on model choice. 5.2.3 Ablation: Without Static-Analysis-Driven Architecture Planning. For the ablation, we remove both the static analyzer and the Architect agent. These components are tightly coupled because analysis_report.json is designed specifically to support blueprint generation. The ablation tests whether pre-computed structural analysis plus explicit architectural planning adds value beyond direct source-to-target transformation. Without them, the Code Developer must identify endpoints from source code, the SAM Engineer must infer resources from generated handlers, and the Consistency Validator loses its architectural ground-truth reference.
Table 3: Comparison of experimental conditions
The source application code is already in this workspace. /output +-- template.yaml \-- lambdas/ \-- <function_name>/ +-- handler.py (or handler.js) \-- requirements.txt (or package.json)
Figure 3: Baseline migration prompt provided verbatim to Cursor and Claude Code.
Dimension
M2S (Full)
LLMBaseline
w/o SA&Arch
Static Analysis Architect Agent Blueprint Agents Tasks (SAM) Validator Domain Knowledge Prompt Guidance
✓ ✓ ✓ 4 spec. 7 (3) 11-point ✓ Detailed
✓ (single) ✓ 1 gen. 2 Removed ✓ High-level
✗ ✗ ✗ 3 spec. 6 (2) Partial ✓ Detailed
spec. = specialized; gen. = generalist; Tasks (SAM) = total tasks (SAM sub-tasks).
RQ4 (Cloud-Native Design) asks whether the generated applications adopt AWS-native patterns. For RQ1–2, we compare against Cursor, Claude Code, and an LLM-Baseline, with two backbone LLMs (Claude Sonnet 4.6, DeepSeek-V3.2) to confirm results are method-driven rather than model-driven.
5.2
Baselines and Ablation
5.2.1 Commercial Baselines. We evaluate Cursor (Agent mode with Claude Sonnet 4.5 (Thinking)) and Claude Code (CLI with Claude Sonnet 4.6), following the methodology of RepoGenesis [29]: each baseline receives the complete monolith source code and a task-level migration prompt (Figure 3) but no pre-computed static
5.3
Evaluation Metrics
We define metrics across two dimensions: deployability and functional correctness. Deployability. We measure deployability through two complementary metrics: Validation Pass Rate (VPR) measures the fraction of generated projects that pass static validation checks. We use sam validate, which verifies SAM template syntax and resource references, together with cfn-lint, which enforces AWS CloudFormation best practices and detects common misconfigurations.
Mono2Sls
Conference’17, July 2017, Washington, DC, USA
Deployment Success Rate (DSR) measures the fraction of projects that achieve functional deployment to AWS: (1) sam build completes without error, (2) sam deploy provisions all resources without CloudFormation rollback, and (3) deployed Lambdas are invocable without systematic failures(e.g., universal HTTP 502 from incorrect handler paths or package structures). We manually inspect invocation errors to distinguish systematic failures from isolated bugs. Functional Correctness. We assess functional quality through two complementary metrics that measure structural and behavioral fidelity respectively. API Coverage (F1) measures the match between generated HTTP endpoints 𝐺 and the reference set 𝑅 of observable business endpoints from the ground-truth monolith (|𝑅| = 76). It is computed as the harmonic mean of precision (how many generated endpoints belong in 𝑅) and recall (how many reference endpoints are generated). Redundant auth endpoints (not in 𝑅) reduce precision; async consumer Lambdas (no HTTP surface) are excluded from both sets. End-to-End Pass Rate (E2EPR) measures the fraction of E2E tests passing against the deployed application, capturing behavioral correctness beyond structural compliance. Let 𝑇𝑖 denote the test suite for application 𝑎𝑖 and 𝑃𝑖 the subset of passing tests: Í |𝑃𝑖 | 1 ∑︁ |𝑃𝑖 | E2EPRmicro = Í𝑖 , E2EPRmacro = (1) 𝑛 𝑖 |𝑇𝑖 | 𝑖 |𝑇𝑖 | We report on Core + Robustness tests (121 out of 145 total); test categories and their applicability to each method are detailed in §5.4. Unless otherwise stated, 𝑇𝑖 refers to Core + Robustness tests applicable to application 𝑎𝑖 .
Environment. Pipeline execution runs locally (Windows). Generated applications are deployed to AWS via sam deploy and tested against live infrastructure (API Gateway, Lambda, DynamoDB). Both backbone LLMs (DeepSeek-V3.2 and Claude Sonnet 4.6) were run at their default inference temperature; all experiments report single-run (pass@1) results per application.
6
Results
We report results for each research question in turn, following the evaluation protocol and metrics defined in §5. Evaluation Protocol. Because the methods differ in deployment success, we use different evaluation procedures. Commercial baselines receive expert-assisted fixes for both validation and deployment failures, which isolates the comparison to functional correctness and reflects their best-case usage scenario. LLM-Baseline and Ablation receive fixes only for validation failures (VPR=0) so they can be deployed for testing, but systematic deployment failures (DSR=0) remain unfixed and are marked non-functional (E2EPR = N/A). Mono2Sls is evaluated on raw output only, because the self-verifying validator is intended to ensure deployment readiness. Under this setup, commercial tools are assessed under their intended collaborative usage model while the research variants are assessed on raw generation quality.
6.1
RQ1: Deployability Table 5: Deployment Results (Raw vs. Evaluated)
Method
5.4
Test Suite and Environment
We design application-agnostic E2E test suites by extracting API contracts from each monolith (endpoint signatures, request/response schemas, and authentication requirements) and using GPT-5.4, separate from the pipeline LLMs, to generate 145 tests covering four categories: Core (CRUD), Robustness (edge cases), Auth (JWT endpoints), and Async (event-driven). All tests then undergo expert review to ensure correctness and coverage. To evaluate methods with different authentication mechanisms under a common interface, we implement an Auth Provider abstraction (CognitoProvider for Mono2Sls; CustomJwtProvider for baselines), so the test logic remains auth-agnostic. The Core+Robustness tests (121) serve as the primary metric for all methods; Auth tests (18) apply only to commercial baselines; Async tests (6) apply only to methods that generate event-driven architectures (qualitative analysis in §6.4). Table 4: Test Suite Distribution App
Core
Rob
Auth
Async
Total
B1: Todo B2: Shopping Cart B3: Bookstore B4: Coffee B5: Airline B6: E-commerce
13 12 12 19 19 24
3 3 4 2 5 5
0 2 4 3 6 3
0 0 1 1 2 2
16 17 21 25 32 34
Total
99
22
18
6
145
M2S-DeepSeek M2S-Sonnet LLM-Baseline-DS LLM-Baseline-SN Cursor Claude Code
VPR(raw)
VPR(eval)
DSR(raw)
DSR(eval)
6/6 6/6 6/6 6/6 2/6 3/6
6/6 6/6 6/6 6/6 6/6† 6/6†
6/6 6/6 3/6 3/6 4/6 4/6
6/6 6/6 – – 6/6† 6/6†
raw = output without any fixes. eval = after applying evaluation-protocol fixes. Italic values differ from raw due to applied fixes. LLM-Baseline DSR failures are not fixed per evaluation protocol (§5.3). † Commercial baselines receive expert-assisted fixes for both validation and deployment failures.
Table 5 reports deployment results. Mono2Sls reaches 100% VPR and DSR for both backbone models, without manual fixes. Commercial baselines produce invalid templates on 2–4 of the 6 applications. Common issues include reserved environment variables, invalid CORS settings, and unsupported Globals combinations. We do not observe these errors in Mono2Sls outputs, likely because generation is constrained by the SAM knowledge base. After expert-assisted validation fixes, both Cursor and Claude Code still fail to deploy 2 applications because of incorrect Lambda Layer directory structures. Mono2Sls avoids these failures through agent specialization and the Consistency Validator’s cross-artifact checks. Both LLM-Baseline variants achieve 6/6 VPR but only 3/6 DSR. Their failures arise from Cognito schema mis-declarations and API definition errors that are syntactically valid yet semantically wrong. cfn-lint does not catch these faults, but Mono2Sls’s Consistency Validator does through cross-artifact comparison with the blueprint and handler code. The same E-commerce identity configuration
Conference’17, July 2017, Washington, DC, USA
Author et al.
error appears under both backbone LLMs, which points to a limitation of single-context generation rather than a model-specific weakness: without separate phases for architecture design, code generation, and template validation, the system cannot reliably maintain structural coherence across all generated artifacts. LLMBaseline DSR values are reported as-is per the evaluation protocol (§5.3); no deployment fixes are applied. Mono2Sls is the only method that reaches 100% VPR and DSR without any manual intervention. The commercial baselines require expert-assisted fixes, and the LLM-Baseline variants still fail to deploy 3 of 6 applications despite producing structurally valid templates.
6.2
RQ2: Functional Correctness Table 6: API Coverage F1 Scores
Method
Micro-F1
Macro-F1
Anti-Pat.
Consumer
1.000 0.987 0.9935 0.974 0.884 0.889
1.000 0.986 0.9928 0.969 0.870 0.879
0 1 1 2 19 19
11 2 0 0 0 0
M2S-DeepSeek M2S-Sonnet LLM-Baseline-DS LLM-Baseline-SN Cursor Claude Code
Anti-Pat. = Redundant auth endpoints. Consumer = Async consumer Lambdas (SQS/EventBridge-triggered, correctly excluded from API surface).
6.2.1 API Coverage. Table 6 presents API Coverage F1 scores. Mono2Sls achieves near-perfect F1 (1.000 for M2S-DeepSeek, 0.987 for M2S-Sonnet), compared to LLM-Baseline variants (DS: 0.994, SN: 0.974) and commercial baselines (0.884–0.889). Much of the gap comes from authentication design. By delegating authentication to AWS Cognito, Mono2Sls does not generate redundant /register, /login, and /auth/me endpoints. Commercial baselines generate 19 such extra APIs across the 6 applications, while LLM-Baseline-SN generates 2 and LLM-Baseline-DS generates 1; the smaller counts for the LLM baselines reflect the same domain knowledge that instructs the model to leave authentication to Cognito. The LLM-Baseline variants still achieve high API F1, which indicates that static analysis input and domain knowledge are often enough for a single-context model to recover the API surface correctly. Yet recovering the interface is not enough to ensure correct behaviour, as the next subsection shows. Table 7: End-to-End Pass Rate (%) on Core + Robustness Tests Method
B1
B2
B3
B4
B5
B6
Micro
Macro
M2S-DeepSeek M2S-Sonnet LLM-Baseline-DS LLM-Baseline-SN Cursor Claude Code
100 100 N/A 37.5 100 100
33.3 33.3 33.3 N/A 26.7 33.3
93.8 93.8 31.3 N/A 31.2 31.2
71.4 76.2 N/A 23.8 100 100
50.0 50.0 37.5 41.7 45.8 87.5
51.7 55.2 N/A N/A 27.6 20.7
64.5 66.1 34.5∗ 34.4∗ 53.7 61.2
66.7 68.1 34.0∗ 34.3∗ 55.2 62.1
N/A = DSR=0 (LLM-Baseline, unfixed per protocol). ∗ Computed over 3 DSR-passing apps only (SN: B1, B4, B5; DS: B2, B3, B5).
6.2.2 End-to-End Correctness. Table 7 compares end-to-end functional correctness. M2S-Sonnet obtains the highest micro-E2EPR at 66.1%, ahead of Claude Code (61.2%) and Cursor (53.7%). The margin is notable because the commercial baselines were allowed expert-assisted deployment fixes, whereas Mono2Sls was evaluated on raw output. The remaining gap therefore reflects generated code quality rather than deployment scaffolding. LLM-Baseline Performance. Despite high API F1, both LLMBaseline variants achieve only about 34% micro-E2EPR (34.5% for LLM-Baseline-DS and 34.4% for LLM-Baseline-SN), computed over the three applications each variant deploys successfully. The contrast exposes a structural-to-functional gap: a single-context LLM can often identify what APIs to generate while still failing to implement the underlying business logic, database access patterns, and cross-function coordination correctly. The F1-to-E2EPR gap reaches about 65pp for LLM-Baseline-DS (99.4% F1 vs. 34.5% micro-E2EPR) and about 63pp for LLM-Baseline-SN (97.4% vs. 34.4%), compared with about 33pp for M2S-Sonnet (98.7% vs. 66.1%). The smaller gap reflects the implementation benefit of staged decomposition and specialized prompting. Backbone LLM Comparison. M2S-Sonnet and M2S-DeepSeek produce similar results: E2EPR differs by 1.6pp (66.1% vs. 64.5%), and both reach 6/6 VPR and DSR. In our setting, pipeline design appears to matter more than the choice of backbone model. The same pattern appears in the LLM baselines, where SN and DS reach nearly identical E2EPR (34.4% vs. 34.5%). The roughly 32pp gap between Mono2Sls and the LLM baselines is therefore more plausibly explained by pipeline structure than by model strength.
6.3
RQ3: Contribution of Static-Analysis-Driven Architecture Planning
We compare the ablation variant (w/o SA&Arch) against M2SSonnet (the same backbone LLM used in the ablation) across deployability, API coverage, and end-to-end correctness. Table 8: Ablation Results: M2S-Sonnet vs. w/o SA&Arch App
DSR
F1
E2EPR
Failure Mode
B1: Todo B2: Shopping Cart B3: Bookstore B4: Coffee B5: Airline B6: E-commerce
✓ ✓ ✗ ✗ ✗ ✓
0.833 1.000 1.000 0.957 0.714 0.962
56.3% 20.0% N/A N/A N/A 37.9%
None None Env var not injected Path variable conflict Layer double-nesting None
w/o SA&Arch M2S-Sonnet
3/6 6/6
0.915 0.987
38.3%∗ 66.1%†
VPR = 6/6 for both variants. M2S-Sonnet F1 and overall E2EPR from Tables 6–7. ∗ micro-E2EPR over 3 DSR-passing applications (B1, B2, B6). † Overall micro-E2EPR (all 6 apps); on the same 3-app subset (B1, B2, B6), M2S-Sonnet achieves 61.7%.
Table 8 shows a clear drop in performance without static analysis and architectural planning. Deployability (DSR: 6/6→3/6). The root cause is the absence of blueprint.json as a shared contract: without a centrally authored endpoint inventory and resource specification, each agent must independently infer structure from source code, leading to
Mono2Sls
cross-artifact inconsistencies that survive template validation but break at deployment. Concretely, all three DSR failures involve handler–template mismatches that cfn-lint cannot detect: missing environment variable injections, inconsistent API path parameters across sibling routes, and incorrect Lambda Layer directory structures. These are precisely the failure modes the Architect and Consistency Validator are designed to prevent. API Coverage (F1: 0.987→0.915). The F1 drop reflects RESTshape drift, not only missing endpoints. Applications with flat API structures (B2, B3) retain perfect F1, whereas those with more complex routing (B1, B5) regress the most. The drift appears as resource hierarchy changes (e.g., B5: /customers/{id}/bookings → /bookings/customer/{id}), HTTP method reassignment (B5: POST → PUT for state transitions, leading to HTTP 405 errors for conforming clients), and path compression in the multi-domain B6 application. Static analysis therefore does more than point to relevant files; it constrains the space of plausible API designs. End-to-End Correctness. On the 3 applications deployable by both variants (B1, B2, B6), M2S-Sonnet reaches 61.7% micro-E2EPR (computed from Table 7: (16+5+16)/(16+15+29)), compared with 38.3% for w/o SA&Arch, a 23.4pp gap on the same application set. Without blueprint-defined Lambda boundaries and dependency relationships, the Code Developer must read the monolith, infer endpoint semantics, and generate handlers at the same time. That broader context hurts implementation accuracy even when deployment still succeeds. Overall, removing static-analysis-driven architecture planning degrades all three quality dimensions: DSR (6/6→3/6), API Coverage F1 (0.987→0.915), and micro-E2EPR on the comparable deployable subset (61.7%→38.3%). The ablation therefore supports the claim that pre-computed structural analysis plus explicit architectural planning adds value beyond direct source-to-target generation.
Conference’17, July 2017, Washington, DC, USA
6.4.2 Asynchronous Communication. Across the 4 applications with detectable event-driven signals in the monolith source (B3– B6), Mono2Sls often reconstructs full event-driven chains. M2SDeepSeek does so in all 4 applications; M2S-Sonnet does so in 2 and produces partial async structure in the other 2 (producer wired, but not all consumers generated). In both variants, the Architect records the communication pattern in blueprint.json, and the downstream agents implement it in code and infrastructure. By contrast, the commercial baselines generate purely synchronous architectures across all 4 applications: neither Cursor nor Claude Code attempts event-driven integration despite clear async signals in the source. Figure 4 (b) shows the difference on the Coffee Shop application. 6.4.3 LLM-Baseline: Hybrid Architecture and Responsibility Confusion. LLM-Baseline variants use AWS domain knowledge, but they often produce hybrid designs that mix cloud-native and monolithstyle components within one application. Qualitative inspection suggests that this pattern comes from blurred architectural responsibilities. First, several applications provision Cognito User Pools while still keeping redundant Users DynamoDB tables, which shows that the model knows how to add Cognito but not when it should replace custom identity storage. Second, some applications declare Cognito resources but omit or misconfigure API Gateway authorizers, leaving part of the authentication logic inside handlers. Third, some async-capable applications fall back to synchronous implementations: queues appear in the template, but no consumer Lambdas are generated. LLM-BaselineDS even combines correct async adoption with incorrect authentication redesign in the same application. This mixed outcome is consistent with a single-context setup that has to resolve several architectural concerns at once. Mono2Sls avoids this by assigning each concern to a narrower agent context.
7 6.4
RQ4: Cloud-Native Design Adoption
Beyond functional correctness, we also examine whether the generated applications adopt AWS-native architectural patterns in two areas. (1) Authentication: AWS Cognito handles user registration, token issuance, and token validation as a managed service; API Gateway authorizers can consume Cognito tokens directly, removing authentication logic from Lambda handlers. (2) Asynchronous communication: AWS SQS and EventBridge let producers and consumers communicate through queues or event buses, which better matches the stateless execution model of serverless systems. 6.4.1 Authentication Architecture. Mono2Sls uses AWS-native authentication in all 6 applications for both backbone models. API Gateway Cognito authorizers [1] protect the routes, handlers read validated claims from the authorizer context, and no custom authentication logic remains in the generated code. In contrast, the commercial baselines retain the monolith’s JWT-based design in all 6 applications for both Cursor and Claude Code, including applicationmanaged token validation, explicit /register//login endpoints, and developer-maintained middleware. Figure 4 (a) shows this contrast on the Coffee Shop application.
Discussion
Mono2Sls is intended for teams maintaining monolithic web backends under scalability and operational cost pressures. Given a monolith repository, the pipeline can produce a deployable SAM application, including Lambda handlers, infrastructure template, and shared layers, without requiring cloud expertise from the developer. M2S-Sonnet required 58–106 minutes per benchmark application (601–3,623 LoC), with execution time dominated by the Code Developer’s iterative source transformation and scaling with application size and backbone LLM choice. By automating architectural decomposition, authentication transformation, and IaC generation, Mono2Sls reduces what practitioners often describe as weeks of manual refactoring effort to hours of automated processing per application.
8
Limitations and Threats to Validity
Benchmark Scope. Our benchmark contains 6 applications derived from AWS reference architectures. Although it covers both major serverless languages and a range of sizes (601–3,623 LoC, 6–26 observable business endpoints), it does not cover every monolith pattern, especially legacy enterprise systems with heavy ORM usage or multiple databases. Future evaluation should include larger industrial applications.
Conference’17, July 2017, Washington, DC, USA
Author et al.
(a) Authentication architecture on Coffee App No /register, /login, /me endpoints Cognito User Pool
orders-post / orders-id-put / config-put
Offload identity to infrastructure
App-managed auth retained jwt.sign({userId, role}, JWT_SECRET, {expiresIn: '24h'});
Keep identity within application code
orders-post / orders-id-put / config-put JWT
Client
API Gateway
Business Lambdas
DynamoDB
Client
// Extract user info from Cognito authorizer const claims = event.requestContext?.authorizer?.claims; if (!claims) return unauthorizedResponse; const userId = claims.sub; // Cognito UUID const userRole = claims['cognito:groups'] || claims.role; if (!isAdmin(userRole)) return forbiddenResponse; // RBAC
Register&Login Lambdas
Userstable
JWT token Business Lambdas
jwt.verify(token, JWT_SECRET); // check decoded role
Mono2Sls (AWS-native auth)
Cursor (JWT-based design)
(b) Async order-journey architecture on Coffee App Rebuilds event-driven pipeline orders-post / orders-id-put / qr-code-post
order-journeyconsumer
Synchronously inserts event records into request path
Achieve decoupling & asynchronous scaling
create-order / update-order
Only physical separation for CRUD operations
direct write
Client
Producer Lambdas OrderJourney Consumer Lambda OrderJourney EventsTable Queue (SQS)
Client
Business Lambdas
OrderJourney EventsTable
// Synchronously insert event records into request path await dynamoDB.put({ TableName: ORDER_JOURNEY_TABLE, Item: { PK: orderId, SK: now(), detailType: 'Order.Created', detail } }).promise();
// Send order event to SQS for audit logging await sendMessage(process.env.ORDER_JOURNEY_QUEUE_URL, { detailType: 'Order.Created', detail: { orderId, userId, eventId } });
Mono2Sls (Event-driven)
Cursor (Synchronous)
Figure 4: Case Study: architecture contrast on the Coffee Shop application (RQ4). (a) Authentication: Mono2Sls routes requests through API Gateway with a Cognito Authorizer, eliminating custom auth logic from Lambda handlers; commercial baselines replicate the monolith’s JWT middleware pattern. (b) Asynchronous communication: Mono2Sls builds a complete SQS eventdriven chain with decoupled producer and consumer Lambdas; commercial baselines produce synchronous direct writes. AWS-Specific. Mono2Sls currently targets AWS SAM. The core ideas in the pipeline, namely static analysis, staged decomposition, and domain knowledge, should transfer to other platforms, but support for Azure Functions or Google Cloud Run would require platform-specific knowledge bases and generators. Async Correctness. While Mono2Sls achieves 100% structural correctness for async design (RQ4), only 67% of async end-to-end tests pass for M2S-Sonnet. We observe two main failure categories: (1) upstream confounding, where earlier operations fail before the async workflow is reached (e.g., payment integration in Airline Booking), and (2) eventual consistency bugs, where producers and consumers are wired correctly but still contain logic errors, such as incorrect event payload schemas or missing idempotency keys. The first category reflects failures outside the async mechanism itself; the second points to limits in current LLM reasoning about distributed semantics. Internal Validity. LLM inference is non-deterministic, and our pass@1 evaluation does not measure run-to-run variance. Singlerun evaluation is standard in repository-level code generation [25], but it remains a limitation. We expect variance to be smaller here than in open-ended generation because the static-analysis inputs are deterministic and each agent follows explicit task instructions
with concrete AWS constraints. Still, only repeated runs can confirm that expectation. Multi-run evaluation with statistical testing is left to future work.
9
Conclusion
Mono2Sls is a static-analysis-driven multi-stage pipeline for automated monolith-to-serverless migration. Rather than asking a single model to solve the entire migration problem at once, Mono2Sls separates the work into four sequential stages handled by specialized tool-using LLM agents and grounds their decisions in static-analysis outputs and a curated AWS knowledge base. The staged organization helps keep architectural decomposition, code transformation, and infrastructure generation aligned more reliably than singlecontext generation. Across 6 benchmark applications (10K+ LoC, 76 business endpoints), Mono2Sls achieves 100% deployment success without manual intervention, 66.1% micro-average end-to-end correctness, 98.7% API-coverage F1, and stronger adoption of AWS-native authentication and asynchronous patterns than the baselines. Commercial baselines trail these results even after expert-assisted deployment
Mono2Sls
fixes, and the ablation study shows that static-analysis-driven architecture planning adds 23.4 percentage points to end-to-end correctness on the comparable deployable subset. The main limitations are benchmark scale and AWS specificity. The current pipeline also does not fully address stateful HTTP session patterns or eventual-consistency edge cases in async workflows. Extending the approach to other serverless platforms and improving LLM reasoning about distributed event semantics are natural next steps.
Data Availability Our pipeline code, benchmarks, and test suites are available at: https://doi.org/10.5281/zenodo.19230004.
Acknowledgments Parts of this paper were written and revised with the assistance of AI language models (including Claude by Anthropic). All experimental results, technical claims, figures, and tables are the authors’ own work; AI tools were used solely for language editing, text organization, and literature search assistance.
Conference’17, July 2017, Washington, DC, USA
References [1] Amazon Web Services. 2024. Amazon Cognito Developer Guide. https://docs. aws.amazon.com/cognito/latest/developerguide/what-is-amazon-cognito.html. [2] Amazon Web Services. 2024. Amazon EventBridge User Guide. https://docs.aws. amazon.com/eventbridge/latest/userguide/eb-what-is.html. [3] Amazon Web Services. 2024. Amazon Simple Queue Service Developer Guide. https://docs.aws.amazon.com/AWSSimpleQueueService/latest/ SQSDeveloperGuide/welcome.html. [4] Amazon Web Services. 2024. AWS Lambda — Serverless Compute. https://aws. amazon.com/lambda/. [5] Amazon Web Services. 2024. aws-samples: AWS Sample Applications and Reference Architectures. https://github.com/aws-samples. [6] Amazon Web Services. 2024. AWS Serverless Application Model (SAM) Developer Guide. https://docs.aws.amazon.com/serverless-application-model/latest/ developerguide/what-is-sam.html. [7] Amazon Web Services. 2024. cfn-lint: CloudFormation Linter. https://github. com/aws-cloudformation/cfn-lint. [8] Amazon Web Services. 2024. Deploy Node.js Lambda Functions with .zip File Archives. https://docs.aws.amazon.com/lambda/latest/dg/nodejs-package.html. [9] Amazon Web Services. 2024. Understanding the Lambda Execution Environment Lifecycle. https://docs.aws.amazon.com/lambda/latest/dg/lambda-runtimeenvironment.html. [10] Amazon Web Services. 2024. Working with Lambda Layers — Packaging Layer Content. https://docs.aws.amazon.com/lambda/latest/dg/packaging-layers.html. [11] Shrikara Arun, Meghana Tedla, and Karthik Vaidhyanathan. 2025. LLMs for Generation of Architectural Components: An Exploratory Empirical Study in the Serverless World. In Proceedings of the 22nd IEEE International Conference on Software Architecture (ICSA). IEEE. [12] Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, and Charles Sutton. 2021. Program Synthesis with Large Language Models. arXiv:2108.07732 https://arxiv.org/abs/2108.07732 [13] Calyo Consulting. 2026. Serverless Computing in Enterprise 2026: What You Need to Know. https://www.calyo-consulting.fr/en/resources/10-serverlesscomputing-enterprise-2026. [14] Mark Chen, Jerry Tworek, Heewoo Jun, Qiming Yuan, Henrique Ponde de Oliveira Pinto, Jared Kaplan, Harri Edwards, Yuri Burda, Nicholas Joseph, Greg Brockman, Alex Ray, Raul Puri, Gretchen Krueger, Michael Petrov, Heidy Khlaaf, Girish Sastry, Pamela Mishkin, Brooke Chan, Scott Gray, Nick Ryder, Mikhail Pavlov, Alethea Power, Lukasz Kaiser, Mohammad Bavarian, Clemens Winter, Philippe Tillet, Felipe Petroski Such, Dave Cummings, Matthias Plappert, Fotios Chantzis, Elizabeth Barnes, Ariel Herbert-Voss, William Hebgen Guss, Alex Nichol, Alex Paino, Nikolas Tezak, Jie Tang, Igor Babuschkin, Suchir Balaji, Shantanu Jain, William Saunders, Christopher Hesse, Andrew N. Carr, Jan Leike, Joshua Achiam, Vedant Misra, Evan Morikawa, Alec Radford, Matthew Knight, Miles Brundage, Mira Murati, Katie Mayer, Peter Welinder, Bob McGrew, Dario Amodei, Sam McCandlish, Ilya Sutskever, and Wojciech Zaremba. 2021. Evaluating Large Language Models Trained on Code. arXiv:2107.03374 https://arxiv.org/abs/2107.03374 [15] Leonardo Rebôuças de Carvalho and Eduardo Araujo Oliveira. 2023. FaaSOriented Node.js Applications in an RPC Approach Using the Node2FaaS Framework. IEEE Access 11 (2023). [16] Simon Eismann, Joel Scheuner, Erwin van Eyk, Maximilian Schwinger, Johannes Grohmann, Nikolas Herbst, Cristina L. Abad, and Alexandru Iosup. 2022. The State of Serverless Applications: Collection, Characterization, and Community Consensus. IEEE Transactions on Software Engineering 48, 10 (2022), 4066–4086. [17] Zhangyin Feng, Daya Guo, Duyu Tang, Nan Duan, Xiaocheng Feng, Ming Gong, Linjun Shou, Bing Qin, Ting Liu, Daxin Jiang, and Ming Zhou. 2020. CodeBERT: A Pre-Trained Model for Programming and Natural Languages. In Findings of the Association for Computational Linguistics: EMNLP 2020. Association for Computational Linguistics. [18] GlobeNewsWire. 2026. Serverless Computing Market Surges to $44.7 Billion by 2029, CAGR 15.3%. https://globenewswire.com/newsrelease/2026/02/10/3235443/0/en/Serverless-Computing-Market-Surges-to-447-billion-by-2029-CAGR-15-3.html. [19] Muhammad Hamza, Muhammad Azeem Akbar, and Kari Smolander. 2023. The Journey to Serverless Migration: An Empirical Analysis of Intentions, Strategies, and Challenges. arXiv:2311.13249 https://arxiv.org/abs/2311.13249 [20] Joseph M. Hellerstein, Jose Faleiro, Joseph E. Gonzalez, Johann Schleier-Smith, Vikram Sreekanti, Alexey Tumanov, and Chenggang Wu. 2019. Serverless Computing: One Step Forward, Two Steps Back. In Proceedings of the 9th Biennial Conference on Innovative Data Systems Research (CIDR). [21] Xinyi Hou, Yanjie Zhao, Yue Liu, Zhou Yang, Kailong Wang, Li Li, Xiapu Luo, David Lo, John Grundy, and Haoyu Wang. 2024. Large Language Models for Software Engineering: A Systematic Literature Review. ACM Transactions on Software Engineering and Methodology (2024).
Conference’17, July 2017, Washington, DC, USA
[22] Ali Reza Ibrahimzada, Kaiyao Ke, Mrigank Pawagi, Muhammad Salman Abid, Rangeet Pan, Saurabh Sinha, and Reyhaneh Jabbarvand. 2025. AlphaTrans: A Neuro-Symbolic Compositional Approach for Repository-Level Code Translation and Validation. Proceedings of the ACM on Software Engineering 2, FSE (2025). [23] Nihal Jain, Robert Kwiatkowski, Baishakhi Ray, Murali Krishna Ramanathan, and Varun Kumar. 2024. On Mitigating Code LLM Hallucinations with API Documentation. arXiv:2407.09726 https://arxiv.org/abs/2407.09726 [24] Juyong Jiang, Fan Wang, Jiasi Shen, Sungju Kim, and Sunghun Kim. 2024. A Survey on Large Language Models for Code Generation. arXiv:2406.00515 https: //arxiv.org/abs/2406.00515 [25] Carlos E. Jimenez, John Yang, Alexander Wettig, Shunyu Yao, Kexin Pei, Ofir Press, and Karthik Narasimhan. 2024. SWE-bench: Can Language Models Resolve Real-World GitHub Issues?. In Proceedings of the 12th International Conference on Learning Representations (ICLR). OpenReview.net. https://arxiv.org/abs/2310. 06770 [26] Anup K. Kalia, Jin Xiao, Saurabh Sinha, Maja Vukovic, and Debasish Banerjee. 2020. Mono2Micro: An AI-Based Toolchain for Evolving Monolithic Enterprise Applications to a Microservice Architecture. In Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). ACM. [27] Patrick Lewis, Ethan Perez, Aleksandra Piktus, Fabio Petroni, Vladimir Karpukhin, Naman Goyal, Heinrich Küttler, Mike Lewis, Wen tau Yih, Tim Rocktäschel, Sebastian Riedel, and Douwe Kiela. 2020. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. In Advances in Neural Information Processing Systems (NeurIPS), Vol. 33. Curran Associates, Inc., 9459–9474. [28] Junwei Liu, Yixuan Chen, Mingwei Liu, Xin Peng, and Yiling Lou. 2024. STALL+: Boosting LLM-based Repository-level Code Completion with Static Analysis. arXiv:2406.10018 https://arxiv.org/abs/2406.10018 [29] Zhiyuan Peng, Xin Yin, Pu Zhao, Fangkai Yang, Lu Wang, Ran Jia, Xu Chen, Qingwei Lin, Saravan Rajmohan, and Dongmei Zhang. 2026. RepoGenesis: Benchmarking End-to-End Microservice Generation from Readme to Repository.
Author et al.
arXiv:2601.13943 https://arxiv.org/abs/2601.13943 [30] Protiviti. 2023. Technical Debt Remains a Major Burden. https://www.protiviti. com/de-de/global-technology-executive-survey-tech-debt-major-burden. [31] Yamina Romani, Okba Tibermacine, and Chouki Tibermacine. 2022. Towards Migrating Legacy Software Systems to Microservice-based Architectures: A DataCentric Process for Microservice Identification. In Proceedings of the 19th IEEE International Conference on Software Architecture Companion (ICSA-C). IEEE. [32] Josef Spillner and Serhii Dorodko. 2017. Java Code Analysis and Transformation into AWS Lambda Functions. arXiv:1702.05510 https://arxiv.org/abs/1702.05510 [33] Yingying Wang, Sarah Bornais, and Julia Rubin. 2024. Microservice Decomposition Techniques: An Independent Tool Comparison. In Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering (ASE). ACM. [34] Jinfeng Wen, Zhenpeng Chen, Xin Jin, and Xuanzhe Liu. 2023. Rise of the Planet of Serverless Computing: A Systematic Review. ACM Transactions on Software Engineering and Methodology 32, 5 (2023). [35] Jinfeng Wen, Zhenpeng Chen, Yi Liu, Yiling Lou, Yun Ma, Gang Huang, Xin Jin, and Xuanzhe Liu. 2021. An Empirical Study on Challenges of Application Development in Serverless Computing. In Proceedings of the 29th ACM Joint Meeting on European Software Engineering Conference and Symposium on the Foundations of Software Engineering (ESEC/FSE). ACM, 416–428. [36] Jinfeng Wen, Zhenpeng Chen, Federica Sarro, Zixi Zhu, Yi Liu, Haodi Ping, and Shangguang Wang. 2024. LLM-Based Misconfiguration Detection for AWS Serverless Computing. In ACM Transactions on Software Engineering and Methodology. [37] Kechi Zhang, Jia Li, Ge Li, Xianjie Shi, and Zhi Jin. 2024. CodeAgent: Enhancing Code Generation with Tool-Integrated Agent Systems for Real-World Repo-Level Coding Challenges. In Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (ACL). Association for Computational Linguistics. [38] Lulai Zhu, Damian Andrew Tamburri, and Giuliano Casale. 2023. RADF: Architecture Decomposition for Function as a Service. Software: Practice and Experience (2023).