Case — Cloudwright

Migrating AWS serverless architectures to GCP — with a plan, not a prompt

Most AI-assisted migration tools take a shortcut: point an LLM at your infrastructure and let it generate code in one shot. Cloudwright is built the opposite way — a deterministic, phase-gated pipeline where AI proposes and a human approves, every step leaves an inspectable record, and nothing gets transformed until the migration plan is signed off.

Type: Applied AI engineering — internal R&D

Status: V1 — Python Lambda migrations complete

Core stack: Python 3.12, Typer, Pydantic v2, SQLite

AI providers: Vertex AI, Anthropic, OpenAI

The problem

Teams migrating AWS serverless workloads to GCP are usually stuck between two bad options. Manual migration is slow and demands deep, current expertise in both clouds. One-shot LLM code generation is fast but unaccountable — no audit trail, no checkpoint before it touches infrastructure, and no way to trust the output without re-reading all of it yourself. Neither is something you'd put in front of a client's production AWS account.

The approach

Cloudwright runs the migration as a phase-gated pipeline. Every stage reads and writes versioned artifacts through a shared SQLite artifact bus — nothing is passed between stages as an in-memory side effect, so every intermediate decision is inspectable and reproducible.

01Ingest

02Analyze

03Graph

04Classify

05Plan

06Transform

07Validate

Artifact bus — SQLite

The Plan stage is the gate: Cloudwright will not transform a single file until a human has reviewed and approved the migration plan it proposes. AI involvement is deliberately narrow and controlled — every LLM call is schema-validated against a strict output contract, temperature-locked, and cached by input hash so the same input never silently produces a different plan on a second run.

Design principles

Intelligence-firstA migration plan must exist and be approved before any transformation runs. No bypass flags.

Artifact-drivenEvery stage produces or consumes a versioned, traceable JSON artifact — nothing passes between stages silently.

Controlled AIAll LLM output is schema-validated, temperature locked, and cached by input hash — the model is never re-invoked on a cache hit.

Intent-preservingMaps to GCP-native services based on inferred workload intent, not a 1:1 service lookup table.

Phase-gatedEach stage is independently executable, produces usable output on its own, and has an explicit exit condition.

Human-governedPlan approval, IAM policy generation, and deployment execution always require a human sign-off.

What it does today

V1 performs full, automated transformations for Python Lambda functions — detecting the deployed IaC format (SAM, CloudFormation, Serverless Framework, CDK, or Terraform), analyzing the workload, and producing a human-approved, intent-preserving GCP-native migration. It also detects, models, and plans migrations for Node.js, Java, and Go workloads, ahead of full transform support for those runtimes.

Clean Architecture throughout — domain logic never touches adapter/SDK types directly
Strict mypy, Ruff linting, and a pytest suite with coverage tracking
Multi-provider AI — Vertex AI (via ADC, no API key required), Anthropic, or OpenAI
Fully containerized (Docker), zero-dependency storage layer (SQLite, stdlib)

Full architecture reference

The diagram below is the real end-to-end architecture drawing — every zone, trust boundary, and approval gate as built, not a simplified marketing version.

REF. cloudwright_e2e_architecture.pngView full size ↗

Cloudwright end-to-end architecture diagram

Watch it run

Have a similar migration or AI-agent problem?

Whether it's a cloud migration, an internal agent, or something that needs the same discipline — plan first, execute with checkpoints — we'd like to hear about it.

Let's discuss it →