Skip to main content
Version: 4.0.0-preview

Migrate

Generate the configuration and checklist files you need to move your app from one platform to another.

expressots migrate <action> [options]
# aliases
expressots mig ...
expressots migration ...

Actions

ActionPurpose
initInteractive: pick a source + target platform and walk through the steps.
generateNon-interactive: pass --from and --to flags.
listShow every supported source → target combination.
analyzeDetect the current platform from artifacts in your repo and recommend targets.

Supported migration paths

FromTo
HerokuRailway, Render, Fly.io
Docker ComposeKubernetes, Railway, Render
GenericDocker, Kubernetes, AWS ECS, GCP Cloud Run, Azure Container Apps

Options

OptionAliasDefaultDescription
--from-f(interactive)Source platform: heroku / compose / generic.
--to-t(interactive)Target platform: railway / render / fly / kubernetes / ecs / cloudrun / aca.
--include-datafalseInclude data migration steps (database dump/restore checklist).
--include-secretstrueInclude a secrets-migration checklist (mapping of env vars).
--dry-runfalsePrint the files that would be generated without writing.
--output-dir-o./migrationFolder the migration scaffold is written to.

Examples

# Interactive
expressots migrate init

# Heroku to Railway
expressots migrate generate --from heroku --to railway

# Compose to Kubernetes with a data-migration checklist
expressots migrate generate --from compose --to kubernetes --include-data

# Just analyze: what platform am I on, what could I move to?
expressots migrate analyze

# Show every supported path
expressots migrate list

What migrate writes

A typical Heroku → Railway scaffold lands in ./migration/heroku-to-railway/:

migration/heroku-to-railway/
├── README.md # Step-by-step checklist
├── railway.json # Railway service config
├── Procfile.notes.md # Mapping from Heroku Procfile
├── env.mapping.md # Heroku → Railway env-var mapping
└── deploy.sh # Optional CLI helper

The exact files vary by source/target pair. All scaffolds include a README checklist so you can sanity-check the migration steps.

See also

  • containerize: emit a Dockerfile that most targets need.
  • costs: compare cloud costs before committing to a migration.
  • profile: audit the resulting Dockerfile.