Inventory the running AWS build
List the Lambda functions, DynamoDB tables, S3 buckets, and state machines that actually serve traffic — not everything the account contains. Note each function’s language; it decides function or worker later.
Declare the replacement in stack.json
Write the KERNSTACK project: gateway routes for the API Gateway surface, functions or workers for handlers, tables, buckets, and workflows. Review the kernstack plan diff with the team before anything deploys.
Export and load the data
Export DynamoDB items as JSON, reshape them to the declared table keys, and load. Copy S3 objects into buckets over HTTPS. Declare search indexes over the loaded data and verify counts against AWS.
Move traffic route by route
Point gateway routes at production one path at a time while AWS keeps the rest. Watch the first routes, then retire each Lambda, table, and bucket only after its traffic reads zero.
What moves from AWS, service by service
Start from the running system, not the account. A typical AWS product build uses a handful of services; the rest of the account is history. Lambda handlers split by language and shape: Go handlers become KERNSTACK functions, which are Go WebAssembly handlers, while Node.js, Python, or PHP code becomes container workers with the matching runtime. Anything that runs for minutes — media jobs, report builders, sync daemons — is a worker regardless of language.
Data moves with exports you run yourself. DynamoDB items export to JSON and load into tables, with the DynamoDB partition key becoming the table key in most designs. S3 objects copy over ordinary HTTPS transfers into buckets. OpenSearch documents re-index: declare a text or vector search index over the new tables and buckets and let the platform build it from source instead of shipping index files.
- IAM roles and policies do not move. Access inside a project is structural: resources in one stack.json belong to one project.
- Secrets Manager and Parameter Store values are re-entered as project secrets; the values never pass through an importer.
- RDS and Aurora have no SQL equivalent on KERNSTACK. Relational data either reshapes into keyed tables or stays on AWS and is called over the network.
Cutover without downtime: run both, move routes last
The safe order is declaration, data, traffic. Declare the KERNSTACK project and get it reviewed as a plan while AWS keeps serving. Load data and run the new project against production-shaped traffic in a preview target. Move public URLs last: gateway routes in stack.json take over path by path, so one API surface can cut over on a Tuesday and the next a week later.
Old AWS resources retire only after their traffic is gone. That sounds slow; it is the opposite. Because both systems run at once, every step is reversible — a route that misbehaves points back at AWS while you read the diff that caused it.
Resource-by-Resource Mapping from AWS
- Lambda (Go) + API Gateway →
functions + gateway routes: Go handlers become Go WebAssembly functions; API Gateway paths become http routes in stack.json. - Lambda (Node.js, Python, PHP) →
workers: Non-Go handlers run as container workers with the nodejs, python, or php runtime — same code shape, longer leash. - EC2, ECS, or long-running jobs →
workers: Processes that outlive a request are declared as workers beside the functions, in the same project. - DynamoDB →
tables: Items export as JSON and load into key-value tables. The partition key usually becomes the table key; secondary-index queries become key design or a search index. - S3 →
buckets: Objects copy over HTTPS. Browser uploads use presigned URLs issued by your functions or workers, as they did with S3 presigning. - Step Functions →
workflows: State machine states become workflow steps: function steps, worker steps, and human steps where the state machine waited for a callback or an approval. - OpenSearch →
search indexes: Declare a text or vector index over tables and buckets and rebuild from source documents. Index files themselves are not migrated. - CloudFront →
gateway prefix routes: Public content is served by a prefix route; set cdn_enabled on the route where cached delivery is needed. There is no separate CDN product to configure.
Frequently asked questions
A typical single-product backend — a dozen Lambda functions, a few DynamoDB tables, one bucket — is days to a few weeks, dominated by key design for the tables and route-by-route cutover, not by data transfer. Accounts with many interdependent services should migrate one product at a time.
No. KERNSTACK imports nothing from AWS consoles, APIs, or Terraform state, and any tool claiming otherwise would be guessing at your architecture. You re-declare the system in stack.json — that re-declaration is the deliverable, because it leaves the whole system readable in one file.
Anything relational (RDS, Aurora) has no SQL target; it reshapes into keyed tables or stays on AWS behind network calls. Exotic services — from EMR to Ground Station — stay where they are. IAM, VPC topology, and CloudFront configuration have no equivalent to import; the project model replaces them rather than translating them.
Related capabilities, architectures, and comparisons
Ship your stack on the Software Lifecycle Cloud.
Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.