Migrating On-Call Rotations to Overrides

Overrides are now the only way to change a shift on a rotation — reassigning a shift, requesting coverage, and removing coverage are all implemented as overrides rather than edits to the generated schedule (see Overrides). To support that, FireHydrant needs to know what a rotation's shifts looked like before any manual changes were made to them, so it can always revert an override back to the original shift.

Rotations that existed before July 24, 2026 were never generated with that information attached, so they aren't ready to use overrides yet. This guide walks through the one-time migration that brings an older rotation onto the overrides system — including how to make sure shifts you've already hand-edited aren't lost in the process, and how to review exactly what will change before you confirm it.

📘

This migration is scoped to a single rotation, not an entire schedule. If a schedule has multiple rotations (for example, a Primary and a Secondary), each one is migrated independently the first time you open its Overrides tab.

Prerequisites

  • You need the Manage Schedules permission on the rotation's team to migrate a rotation.
  • Know which upcoming shifts on the rotation, if any, were manually reassigned outside of the normal schedule (swaps, vacation coverage, etc.) — you'll need to identify these yourself in Step 4.

Step 1: Open the Overrides Tab for the Rotation

  1. Navigate to the team's On-call Schedules tab and find the rotation you want to check.
  2. Click the ••• menu next to the rotation and select Manage Rotation.
  3. Switch to the Overrides tab.

If the rotation has already been regenerated since July 24, 2026, you'll see the normal override tools described in Viewing and editing overrides — you don't need this guide. If it hasn't, you'll instead see a message explaining that overrides aren't enabled yet for this rotation, along with a warning about the July 24, 2026 cutoff and three collapsed sections below it: Responders (Step 1 of 3), Effective Date & Time (Step 2 of 3), and Shifts to preserve (Step 3 of 3). The rest of this guide walks through those three sections, plus the live comparison calendar shown alongside them.

📘

The Current vs. Regenerated calendar on the right side of this view is visible the entire time you're working through the three sections below — it isn't a separate step. See Watching the Current vs. Regenerated Preview for what it shows and how to use it.

Step 2: Confirm Responders

Expand Responders (Step 1 of 3) to review who's on the rotation. This is the same responder list and order used by the rotation's normal configuration — you're not required to change anything here, but it's worth confirming it's still correct before you regenerate, since the rebuilt shifts will be assigned from this list.

Step 3: Choose an Effective Date and Time

Expand Effective Date & Time (Step 2 of 3) and set the point in time from which shifts should be rebuilt:

  • Last handoff — rebuild starting from the rotation's most recent handoff, leaving everything before that point untouched.
  • Now — rebuild starting immediately, which may split whoever is currently on call mid-shift.

Shifts entirely before the effective date and time are left as-is; anything at or after it is regenerated. The next section shows you exactly which upcoming shifts fall into that window.

Step 4: Preserve Overrides for Manually-Edited Shifts

⚠️

This is the step that determines whether your past manual shift changes survive the migration. Regenerating a rotation rebuilds its shifts from the rotation's configured responders and handoff pattern going forward — anything that isn't captured as an override before you regenerate is replaced by what the rotation would normally produce.

Because these older shifts were never tracked as overrides, preservation doesn't happen automatically here the way it does for a rotation that's already on the overrides system (see Editing Schedules & Rotations) — there's nothing yet for FireHydrant to preserve. Instead, expanding Shifts to preserve (Step 3 of 3) shows you a checklist where you manually flag which upcoming shifts to protect before you regenerate:

  1. Expand Shifts to preserve. This lists the rotation's upcoming shifts at or after the effective date and time you chose in Step 3.
  2. Check any shift you know was manually reassigned, shortened/lengthened, or otherwise changed by hand and that you want to keep exactly as it is.
  3. Click Create overrides. Each checked shift is converted into a real override record, so it's now tracked and preserved the same way any other override is — including through every future edit or regeneration of this rotation.

Any shift you don't check here will be regenerated to match the rotation's normal pattern — you'll see this reflected immediately in the preview described below.

Watching the Current vs. Regenerated Preview

Alongside the three sections above, the Overrides tab shows a calendar with two rows — Current and Regenerated — for as long as you're working through this migration:

  • Current — the rotation's actual, persisted shifts as they exist today.
  • Regenerated — a live simulation of what the rotation's shifts will look like after this migration, updating immediately as you adjust responders, the effective date, or which shifts you preserve in Step 4.

The calendar has its own toolbar — a date range with Today/back/forward controls, zoom in/out, a duration selector (e.g. 2 Weeks), and a Preview toggle — so you can scrub through future weeks and confirm the regenerated shifts look right before committing anything. Use it to check that every shift you preserved in Step 4 shows up correctly on the Regenerated row, and to catch any shift that changes unexpectedly because it wasn't flagged to preserve.

Nothing here is saved until you confirm in the next step — you're free to go back and adjust any of the three sections and watch the Regenerated row update again.

Step 5: Confirm the Regeneration

Click Regenerate rotation to confirm. This will:

  • Delete and rebuild the rotation's shifts from the effective date and time forward, based on its configured responders and handoff pattern.
  • Re-apply every override that overlaps that window — including the ones you just created in Step 4 — on top of the rebuilt shifts.

Once this completes, the rotation is fully on the overrides system. You won't see this migration prompt again for it, and it now behaves like any other rotation described in Overrides — including the fact that, from this point forward, any override you create is preserved automatically across future edits or regenerations, with no need to repeat the "shifts to preserve" step again.

📘

If you'd rather skip choosing individual shifts and just accept a clean slate, you can regenerate without creating any overrides in Step 4 — the rotation will simply come out matching its configured pattern exactly, with no manual history carried over.

Viewing Current Shift vs. Regenerated Rotation

The Regenerated preview described above is easy to confuse with a rotation's ongoing current/next shift, but they answer different questions:

  • Current (and next) shift — this is the live, ongoing state of the rotation: who's on call right now and who's up next. You can see it in the team sidebar, on shift popovers, and by switching the on-call schedules calendar to the Current/Next Shifts viewing mode (see Viewing schedules). This view exists at all times for every rotation, whether or not it's been migrated.
  • Regenerated rotation preview — this only exists while you're actively inside the migration/reset flow described above. It's a side-by-side simulation — not yet saved — that lets you compare the rotation's real, persisted shifts against what your in-progress changes would produce, so you can catch problems before clicking Regenerate rotation. Once you confirm the regeneration, this preview disappears and the "Regenerated" row becomes the new "Current" state.

In short: check current/next shift any time you want to know who's on call. Only look for the Current vs. Regenerated comparison while you're mid-migration and deciding whether to commit a change.

Next Steps


Did this page help you?