Migrate without losing coverage

Use a new monitor key only when you intentionally want separate history. Reusing the existing key keeps incident and execution continuity.

Manual pings to a framework integration

Check the matching guide's current SDK availability before migrating. If SDK setup is temporarily unavailable, keep the existing manual HTTP reporting and follow that guide's HTTP setup. Manual HTTP does not discover scheduled jobs automatically.

1. Install the matching framework package only when its guide lists SDK setup as available.
2. Configure it with the same application key as the manual monitor.
3. Ensure the discovered recurring-job key matches the existing manual key, using the integration's override attribute or decorator when necessary.
4. Deploy and confirm registration plus one real execution.
5. Remove the old manual heartbeat or wrapper only after the framework lifecycle is visible.

Never run both paths indefinitely: duplicate terminal events make execution history ambiguous.

Completion-only heartbeats to lifecycle tracking

1. Keep the same monitor key and schedule.
2. Add HTTP start plus exactly one complete or fail terminal event using the HTTP API, or use an available SDK's wrapper after checking its guide.
3. Re-throw the original job exception after recording failure.
4. Verify one successful and one controlled failed execution.

The schedule and history remain attached to the existing monitor. Lifecycle tracking adds duration and stuck-run evidence.

Deprecated framework entrypoints

• Hangfire: replace configuration.MonitorAll() with builder.Services.AddCronRadarHangfire() after Hangfire storage and server registration. Check the Hangfire guide for the published release's retry and cancellation limitations.
• Quartz.NET: await scheduler.MonitorAll(apiKey) after the scheduler and recurring triggers are configured. Replace deprecated synchronous calls before removing the old package version.
• Celery: SDK connections are temporarily unavailable. Use the Celery guide's manual HTTP setup and keep the existing scheduler. This setup does not discover periodic tasks automatically. Wait until the guide confirms SDK availability before migrating to automatic discovery.

Move an API key between environments

Do not copy the production key. Create a CronRadar application for the destination environment, create a new key, update its secret store, deploy, and verify. After the destination reports a real run, revoke any key that no longer has a deployed consumer.

Move from another heartbeat service

Run both services for one normal schedule window. Register CronRadar with the same five-field schedule, verify a real successful run, and review the channels and recipients in Alerts. Confirm notification delivery with the intended recipient before removing the old heartbeat. Use an available channel test or a harmless job in a separate test application if needed. Avoid changing the scheduler and monitoring provider in the same deployment; keeping the scheduler stable makes rollback and diagnosis straightforward.