Migration

Adopting Axis for an existing system is incremental, not big-bang. You can bring existing resources under Axis by reference or adoption, add Axis stacks alongside what you have, and migrate surface by surface. This page orients you; the repository’s MIGRATION_GUIDE.md carries the step-by-step detail.

Bring existing resources in

axs add import authors a config entry for a resource that already exists — reference it (Axis creates nothing, never mutates it) or adopt it under stack management for a later cdk import. The five kinds are bucket, queue, topic, secret, and key. See Importing Existing Resources.

Add Axis stacks alongside your own

Because cross-stack wiring is SSM-only and the framework is layout-agnostic, an Axis stack can sit next to your existing raw-CDK stacks without a rewrite — see Add Your Own Stack. You can migrate one surface (say, a new API) onto Axis while the rest stays as-is.

The one rule that never bends

When you adopt an existing stateful resource, its CloudFormation logical ID must line up — a mismatched logical ID replaces the resource, destroying data. Read Logical-ID Permanence and Logical-ID Permanence When Extending before adopting anything stateful.

The detailed guide

The step-by-step migration procedure lives in the repository’s MIGRATION_GUIDE.md. This page is the map; that file is the route.