## Migrate Railway app: Django

Move Django compute from Railway 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.

### Summary
Source procedure: Export variables from the Railway service (Variables tab or `railway variables`) into an env file kept out of the repository.  
Not migrated automatically: Railway cron schedules, volumes and private networking are not migrated; persistent data belongs in a managed database, a bucket or an Ample volume.  
Cutover: Add the custom domain with `ample domain add`, update DNS from the Railway target, keep the Railway service until verified, then remove it.  
Rollback: keep the source untouched until you confirm; nothing at the source is changed or deleted by this guide.

### Workflow Steps
1. **Inventory the source**: List what Railway app provides beyond the component you are moving. Out of scope here: Railway cron schedules, volumes and private networking are not migrated; persistent data belongs in a managed database, a bucket or an Ample volume.
2. **Source step 1**: Export variables from the Railway service (Variables tab or `railway variables`) into an env file kept out of the repository.
3. **Source step 2**: Translate `railway.json`/Nixpacks settings into the repository's build and start commands; Ample detects Node and Python builds itself.
4. **Source step 3**: Note Railway-only features in use: cron schedules, volumes, private networking, templates.
5. **Deploy on Ample in parallel**: pip install into .ample/python from requirements.txt, then waitress serving project.wsgi from run.py reading PORT on the python-3.12 template. Pass the exported variables with --env; keep the source running.  
   Command: `ample deploy . --name  --public --start "python3 run.py" --env-file .env.production`.
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 Railway target, keep the Railway service until verified, then remove it.
8. **Rollback**: Point DNS or configuration back to the source. The source was never modified; deletion is a separate, user-executed step after validation.

### Limitations
- Documentation only: nothing is executed automatically and no execution binding is offered.
- The source-side procedure is documented from Railway 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: Railway cron schedules, volumes and private networking are not migrated; persistent data belongs in a managed database, a bucket or an Ample volume.

### Cost Estimate
- **Monthly Amount**: $10.00 (USD)
- **Basis**: Size prices from pricing.toml (loaded by the API) at build revision.
- **Components**:
  - App server: size `s-1vcpu-1gb`, quantity: 1, monthly amount: $5.00
  - Managed PostgreSQL database: size `s-1vcpu-1gb`, quantity: 1, monthly amount: $5.00
  - **Note**: Destination always-on monthly price of the tested sizes; apps auto-pause when idle. Source costs are unknown to Ample.

### Success Checks
- Destination app responds on its public URL.
- Configuration-secrets check from the destination example.
- Relational-records check from the destination example.
- Data or object counts and checksums match the source.

### Examples
1. **Django pattern fixture (destination)**: Verified destination basis: Django compute.

### Conclusion
This guide provides a comprehensive approach to migrating your Django application from Railway to Ample, addressing core steps, possible limitations, and operational costs.