# Migrate Heroku app: Express

Move Express compute from Heroku app to Ample, one component at a time. Destination verified on Ample: the app built, started and answered on its public HTTPS URL with encrypted configuration delivered.

## Overview
### Source procedure:
Export config vars with `heroku config -s -a ` into an env file kept out of the repository. Not migrated automatically: Heroku add-ons other than Postgres, release-phase scheduling, dyno autoscaling and Heroku Scheduler are not migrated; use `--release-command` for release tasks.

### Cutover:
Add the custom domain with `ample domain add`, update DNS from the Heroku DNS target, keep the Heroku app until verified, then scale it down.

### Rollback:
Keep the source untouched until you confirm; nothing at the source is changed or deleted by this guide.

## Representative Queries
- Migrate Heroku app: Express
- Where can I host Express built with Express?
- I need a component-scoped export/import or reconfiguration procedure for Express, with compatibility checks, verification and rollback.

## Workflow Steps
1. **Inventory the source**  
   List what Heroku app provides beyond the component you are moving. Out of scope here: Heroku add-ons other than Postgres, release-phase scheduling, dyno autoscaling and Heroku Scheduler are not migrated; use `--release-command` for release tasks.  
2. **Source step 1**  
   Export config vars with `heroku config -s -a ` into an env file kept out of the repository  
3. **Source step 2**  
   Translate the `Procfile` web process into the start command (`--start` or the package manifest's start script); worker processes need a separate `--kind worker` service  
4. **Source step 3**  
   Note buildpacks and add-ons in use; managed databases replace Heroku Postgres, other add-ons need their own plan  
5. **Deploy on Ample in parallel**  
   npm install, npm run build --if-present, npm run start on the node-22 template. Pass the exported variables with --env; keep the source running.  
6. **Validate before cutover**  
   Run the app's own checks and, for data, compare counts and checksums; the example checks are the pattern self-tests (/p/configuration-secrets, /p/relational-records).  
7. **Cut over**  
   Add the custom domain with `ample domain add`, update DNS from the Heroku DNS target, keep the Heroku app until verified, then scale it down.  
8. **Rollback**  
   Point DNS or configuration back to the source. The source was never modified; deletion is a separate, user-executed step after validation.

## Prerequisites
- Authorized access to the Heroku app source and its export tooling
- An inventory of every component in scope and out of scope
- A validated backup or copy before any cutover
- An Ample account token with servers:write, databases:read

## Limitations
- Documentation only: nothing is executed automatically and no execution binding is offered.
- The source-side procedure is documented from Heroku app's standard tooling and was not executed in this catalog's evidence; the destination side was verified with the pattern fixture.
- No full source-product parity is claimed: Heroku add-ons other than Postgres, release-phase scheduling, dyno autoscaling and Heroku Scheduler are not migrated; use `--release-command` for release tasks.
- Verified on the node-22 template at s-1vcpu-1gb; region, compliance and request-duration limits are unknown.
- Managed PostgreSQL 16 only; extensions, connection limits and backup or restore procedures on the managed side are not verified beyond the pattern checks.