Render Migrate From Heroku

1. list_apps — let user select which app to migrate
2. get_app_info — capture: app name, region, stack, buildpacks, config vars
3. list_addons — identify Postgres, Redis, Scheduler, third-party add-ons
4. ps_list — capture dyno types (web, worker, clock), sizes, counts

From the buildpack URLs, determine runtime. From the config or Procfile, determine start commands. See the buildpack mapping for buildpack-to-runtime and Procfile-to-service mapping.

Present a summary:

App: [name] | Region: [region] | Runtime: [node/python/ruby/etc]
Build command: [inferred from buildpack]
Processes:
  web: [command from Procfile] → Render web service
  worker: [command] → Render background worker (Blueprint only)
  clock: [command] → Render cron job
  release: [command] → Append to build command
Add-ons: Heroku Postgres (standard-0), Heroku Data for Redis (mini)
Config vars: 14 total (list names, not values)

Step 2: Pre-Flight Check

Before creating anything, validate the migration plan and present it to the user. Check for:

1. Runtime supported? If buildpack maps to docker, warn user they need a Dockerfile
2. Worker dynos? Flag these — can be defined in a Blueprint (type: worker, minimum plan starter), but cannot be created via MCP tools directly
3. Release phase? If Procfile has release:, suggest appending to build command
4. Static site? Check for static buildpack, static.json, or SPA framework deps — use create_static_site instead of create_web_service. See detection rules in the buildpack mapping.
5. Third-party add-ons? List any add-ons without direct Render equivalents (e.g., Papertrail, SendGrid) — user needs to find alternatives and update env vars
6. Multiple process types? If Procfile has >1 entry, each becomes a separate Render service (except release:)
7. Repo URL available? Ask user for their GitHub/GitLab repo URL (required for service creation)
8. Database size? If Postgres is Premium/large tier, recommend contacting Render support for assisted migration

Present the full plan as a table:

MIGRATION PLAN — [app-name]
─────────────────────────────────
CREATE (include only items that apply):
  ✅ Web service ([runtime], starter) — startCommand: [cmd]
  ✅ Background worker ([runtime], starter) — startCommand: [cmd]
  ✅ Cron job (starter) — schedule: [cron expr] — command: [cmd]
  ✅ Postgres (basic-1gb)
  ✅ Key Value (starter)

METHOD: [Blueprint | MCP Direct Creation]

MANUAL STEPS REQUIRED:
  ⚠️ Custom domain: [domain] — configure after deploy
  ⚠️ Replace add-on: [name] → find alternative

ENV VARS: [N] to migrate, [M] filtered out
DATABASE: [size] — pg_dump/pg_restore required
─────────────────────────────────
Proceed? (y/n)

Wait for user confirmation before creating any resources.

Choose Creation Method

After the user approves the pre-flight plan, select the creation method:

Use MCP Direct Creation when ALL are true:

• Single web or static site service only
• No background workers or cron jobs
• No databases or Key Value stores needed

Use Blueprint (recommended for most migrations) when ANY are true:

• Multiple process types (web + worker, web + cron, etc.)
• Databases or Key Value stores needed
• Background workers in the Procfile
• User prefers Infrastructure-as-Code configuration

Most Heroku apps include at least a database, so Blueprint is the default path. If unsure, use Blueprint.

Step 3A: Generate Blueprint (Multi-Service)

Generate a render.yaml file using the projects/environments pattern to group all migrated resources in a single Render project. See the Blueprint example for a complete example and the Blueprint YAML spec for the full reference.

Use the correct default plan for each service type. Since Heroku has no free tier, default to the cheapest paid Render plan (upgrade if the Heroku plan maps higher):

Blueprint structure: