Migration checklist: 4schools → Vercel Pro
Current
Railway
$16.37/mo
(96% bandwidth)
Target
Vercel Pro
$0.00/mo
(fits in 1 TB included allowance)
Portability
Saving
$16.37/mo
Bring your own OpenAI or Anthropic key in Connections. Your key is encrypted and billed by your provider.
- Open the service's repository in your IDE (Cursor or VS Code recommended) and create a new feature branch — for example migrate/4schools-to-vercel. Every change in the rest of this checklist should be a commit on that branch, never a manual edit inside a dashboard text box.
- Confirm the workload is genuinely portable: read the README and grep the codebase (railway, process.env.RAILWAY_*, vendor SDK imports) for Railway-specific runtime APIs, env vars, or build hooks.
- Spin up a non-production deployment on Vercel from the feature branch. Use a throwaway subdomain (e.g. *.vercel.app). Wire test env vars only; do not point real traffic yet.
- Mirror outbound integrations (Cloudflare R2, third-party APIs, Postgres connection strings) to the new environment. Use your IDE to search for hardcoded URLs / IDs / regions that may need updating.
- Smoke-test the Vercel deployment for 24–72 hours. Compare error rates, p95 latency, and cold-start behaviour to Railway. If anything regresses, stop here and fix it on the branch.
- The cutover (the only irreversible step): lower DNS TTL to 60 seconds at least 24h before. On migration day, swap the CNAME / A record to Vercel, monitor real traffic split for ~1 hour, then raise TTL back.
- Pause — do not delete — the original Railway service for at least 7 days. This is your cheap rollback insurance.
- After 7 days of clean operation, re-run npm run audit:all to confirm the bill change is reflected. Then delete the paused Railway service.
Cost Doctor never moves anything for you. Every step is manual and reversible up until the DNS cutover.