Your Render Migration Checklist: How to Verify Everything Is Working

Migrating your app to a new service can be scary. Render makes the deployment side easy, but a green deploy doesn’t mean everything is working. Silent failures are often the most dangerous kind. They go unnoticed until a customer calls to report a broken webhook or you realize the queue depth has been climbing since the cutover and nobody has caught it yet.

The migrations that explode on deploy are not the ones you should fear. It’s those that look fine for three days.

If you’re planning a move to Render or you’re already mid-migration, this checklist covers the real-world failure points you need to verify before you call it a day.

Capture a Pre-Migration Performance Snapshot

You won’t be able to check for parity unless you have a baseline of how everything was functioning before you made any changes. So, prior to any updates, here’s what you need to do:

• Pull your overall average and 95th percentile/p95 response time for the last seven days (this metric will give you an idea of what could be causing those long response times).
• Note your throughput (requests per minute at peak).
• Take note of your error rate and your top 3 to 5 error types during that time period.
• Find your slowest endpoints.
• Review your queue depth and how long it typically takes to process a job in the queue.

If you skip this, you will be staring at dashboards at 2 a.m., wondering if the page load time is really different on Render or if it has always just been somewhat slow.

AppSignal’s performance dashboard makes pulling these numbers simple. You want to record them all somewhere for reference during and after the cutover, and not just rely on memory.

Verification Checklist

Here’s what you need to work on immediately after your initial cutover.

1. App Boots and Serves Real Traffic

A successful Render health check only shows that your service is responding, not that your application is actually working. To verify this, open the app in a browser, sign in, navigate through key pages, and make sure the health check covers important dependencies, like your database, instead of a simple /ping endpoint that always returns 200 OK.

To be on the safe side, confirm that Render's health check path points to something that genuinely reflects app health. If it's set to /ping and your database is down, Render will think the service is healthy.

2. Environment Variables and Secrets

Missing environment variables are very common when deploying your application, and they're often the silent killers of platform migrations. You do not need the var for your payment processor service until someone tries to check out; likewise, the Slack webhook key doesn’t matter until you attempt to notify someone via that webhook.

You should always diff your env var list between old and new platforms. One of the quickest ways to do this is to export both lists and run the diff command in your terminal. Keep an eye out for any keys in your file that do not appear to be in well-known and obvious formats.

Then, confirm secrets actually resolve at runtime. For example, if an environment variable points to a stale secret manager reference or is a literal string that should be interpolated to return a value, then you do NOT have a functioning secret.

3. Database Connectivity and Migrations

There are two simple parts you need to check here, and it’s easy to get either one wrong:

First, verify that your application connects to the correct database. Don't assume old staging URL or old connection strings won't accidentally get through. Second, check all migrations have been run/accessed, whether through manual or automatic (deployment) processes, by checking both the database and deployment logs.

4. Background Jobs, Workers, and Queues

On Render, workers are separate services. They don't exist just because you’ve deployed your web service. Confirm that all worker services are running before proceeding to enqueue a test job for those services, and make sure that the test job runs to completion.

To check the worker service process state, monitor the worker queue during the first few hours the new deployment is up and running. If you see the queue depth slowly increasing, that means the worker is falling behind in its ability to process jobs.

5. Scheduled / Cron Jobs

Render cron jobs are separate from web services, so they can be easily overlooked when transitioning to Render's deployment environment.

For each scheduled job you had in your old hosting environment, verify that there is a corresponding Render cron service. After the cutover occurs, ensure that each Render cron service has run successfully and terminated properly.

Each cron service must show a proper exit code, not just appear in the dashboard.

6. Outbound Integrations

Run E2E tests as well as configuration checks for any outbound integrations you have (e-mail, payment, webhooks, third-party APIs).

Also, watch for egress IP changes: if an external service has an IP allowlist and your old host had a fixed outbound IP, the new Render deployment likely has a different one. This can break integrations silently with a 403 you may not catch.

7. Error Rate Parity

Compare the volume and types of errors against your baseline established. A major new error detected after the cutover generally indicates a configuration issue, not an application defect.

AppSignal breaks errors down by deploy, so any spikes after the cutover can be traced back to the migration instead of getting buried in the overall system noise. That significantly reduces the effort required to correlate timestamps manually.

8. Performance Parity

Your response times should settle close to the baseline you recorded before the migration. If your p95 latency suddenly increases or jumps, it usually points to something that has changed after the move. The cause could be the instance size, connection pooling, cold starts, or even where your database is hosted, so try to compare results after the service has been running for about ten minutes instead of relying on the very first request.

9. Logs Are Flowing

Make sure all your logs still end up in the place where your team normally checks them. While Render provides a built-in log feature, any external log pipelines should also be working.

Sending Render Log Streams to AppSignal lets you keep logs, errors, and performance data together instead of switching between separate dashboards. That's why it's worth setting it up before the migration.

10. Deployments Are Tracked

If you’ve set the RENDER_GIT_COMMIT environment variable to your Render deployment information, AppSignal automatically finds and adds a deployment marker to your AppSignal graphs. This makes it much easier to answer the question, "Did this deploy cause it?" The marker also appears on both error and performance graphs, so you can visually correlate the two without having to do so manually.

11. Uptime and Alerting

Make sure to add an uptime check for a route that traverses your entire stack, rather than just sending a basic ping request back to your server.

Set alert thresholds for error rates, response times, and queue depth early. During the initial 72-hour period, you should be notified about any issues rather than having to look at the dashboard to see if there are any. There’s no other reliable way to catch issues, like a cron job failing when it runs at 2 a.m. after the deployment.

The First 72 Hours

Just because you’ve deployed successfully doesn’t mean your cutover is complete. You can only claim this after the application has passed through one full cycle: a maximum daily workload on your servers, the highest load during the night from database backups, and weekly reports generated by cron jobs.

It's common for a system to run correctly under average load, just to crash when large nightly jobs or other types of heavy processing occur.

To be on the safe side, always keep your existing environment warm. Keep the servers running and the database available in case it needs to be rolled back to the previous version. That means not terminating the old service or database immediately, and not invalidating sessions or API keys that the old environment needs to function.

Next Steps

Migrating infrastructure is rarely flawless. Once you have cleared the checklist and your new Render environment has run clean for a full traffic cycle, a few things are worth setting up (if you haven't done it already):

• AppSignal deploy markers (might be already configured if you're using RENDER_GIT_COMMIT, but this is still worth verifying).
• Render Log Streams into AppSignal by setting up log forwarding so you're not split across two dashboards at different times.
• Creating your own custom post-migration dashboard for tracking the KPIs from your baseline, so you have a permanent reference point.
• Also, if there are business-level metrics that matter (orders processed, jobs completed), track those directly using AppSignal's custom metrics.

If you haven't set up AppSignal on Render yet, the Ruby, Node.js, Python, and Elixir install guides take about five minutes.