Migration Guide
Use this guide when moving from Lift or legacy Lambda-handler patterns to AppTheory’s contract-first, cross-language runtime. AppTheory is migration-oriented, but it is not a promise of drop-in API identity.
Lift → AppTheory (Go)
Start here:
docs/migration/from-lift.mddocs/migration/appsync-lambda-resolvers.mddocs/migration/g4-representative-migration.mddocs/api-reference.mddocs/testing-guide.md
✅ CORRECT: treat migration as a parity exercise:
- keep behavior equivalent where contract defines it
- document and test any intentional differences
Migration plan
This checklist is the shortest cross-language path from a legacy handler shape to the canonical AppTheory runtime.
- Confirm the current runtime entrypoint and Lift-specific imports.
- Rewrite or replace Lift imports with AppTheory equivalents.
- Move mixed-trigger Lambdas to
HandleLambda,handleLambda, orhandle_lambdaunless a narrower adapter is required. - For AppSync resolvers, keep the standard direct Lambda event shape and switch to
ServeAppSync,serveAppSync,serve_appsync, or the universal dispatcher. - Run parity, snapshot, and docs checks before rollout.
AppSync note:
- Standard AppSync direct Lambda resolver events are supported without request mapping template changes.
- Resolver metadata is available through
AsAppSync(),asAppSync(), andas_appsync(). - See
docs/migration/appsync-lambda-resolvers.mdfor wiring and route-shaping details.
Migration commands
Use the migration helper in dry-run mode first:
./scripts/migrate-from-lift-go.sh -root ./path/to/service
go run ./cmd/lift-migrate -root ./path/to/service
Apply rewrites only after reviewing the diff:
./scripts/migrate-from-lift-go.sh -root ./path/to/service -apply
go run ./cmd/lift-migrate -root ./path/to/service -apply
UNKNOWN: no broader stable public CLI contract is documented for cmd/** beyond the Lift migration helper.
From raw AWS Lambda handlers
✅ CORRECT: migrate in this order:
- Wrap your handler logic into an AppTheory handler (
Context -> Response). - Add routes and middleware.
- Switch the AWS entrypoint to the matching adapter.
- Add contract tests or examples for the behavior you rely on.
Validation
Run these before cutting traffic to the migrated path:
./scripts/verify-contract-tests.sh
./scripts/verify-api-snapshots.sh
./scripts/verify-docs-standard.sh
make rubric
If the migration changes exported APIs, refresh snapshots before re-running verification:
./scripts/update-api-snapshots.sh
./scripts/verify-api-snapshots.sh
If a migration requirement is not yet confirmed by snapshots or tests, keep it explicit:
UNKNOWN:for an interface or behavior that is not yet verifiedTODO:for the concrete follow-up needed before migration is complete