Worked case study
What the twelve steps ask of a department when the change is not optional.
Most of the Technology Adoption Roadmap assumes a department chooses whether to act. The move from NFIRS to NERIS was not that. Every fire department in the country that reports incident data had to move, on a national timetable nobody local set.
That makes it a useful example rather than a useless one. When the destination is fixed, everything the roadmap actually asks of you is still in play — what your local problem is, what your baseline was, which of your systems already do the work, what the five-year cost is, who owns the thing afterward, and whether anyone measured the result.
A department may not control whether the environment changes, but it still controls how deliberately it prepares for and implements that change.
The facts about NERIS and the retirement of NFIRS below come from published U.S. Fire Administration material, and each is traceable to a source at the foot of this page.
Everything else — the local problems, the baselines, the stakeholder lists, the pilot design, the cost lines — is written as an example of how a department could apply each step. It is labelled as such. No department's actual results are reported here, because none were provided to the Hub. Where you see the label, read it as a worked illustration and not as evidence.
Verified against USFA sources on the date this page was last reviewed. Check them against the sources before relying on any of it — dates in a national transition move.
The tempting problem statement here is the one that is not a problem statement at all.
"We need NERIS" is true and useless. It is the destination, and it was set nationally. It tells you nothing about what has to change locally, which means it cannot tell you what to buy, what to configure, what to train, or how you would know afterward whether any of it worked.
The local problems are the ones worth writing down, because those are the ones your department actually has to solve.
Example department application
Example department application
Step 11 has nothing to compare against unless somebody wrote these down first. Measure your own — no figures are supplied here, and any number offered as typical would be made up.
Example department application
A reporting change reaches further into a department than almost any other technology change, because everyone writes reports. The people who feel it, the people who own the budget, and the people whose behavior has to change are rarely the same people.
Example department application
Written as operational requirements, not as a product's feature list. Each of these should be justifiable by what the department has to accomplish.
Example department application
The most expensive mistake available at this step is buying a second system to do something the first system already does. Work through what you own before looking at what you could buy.
Do the archaeology before buying another system.
Example department application
A generic product tour is not a demonstration. Bring one of your own incidents and make the vendor drive it end to end, in front of the people who will actually do the work.
Example department application
Define what success looks like before the pilot starts, not after. A pilot that only ever sees clean data on day shift has tested nothing.
Example department application
A reporting transition has a long tail of cost, and most of it is not on anybody's quote. Cost the five-year number, not the first-year one.
Who pays on Day 366?
Example department application
Four owners, not three. The sustainment owner is the one who is still holding this in year three, and the one most often left unassigned.
Example department application
This is where a technically successful transition still fails. The crew that was not in the pilot never heard why it mattered, and the training happened on a day they were off.
Example department application
Two chains have to work, and they fail differently. CAD into the RMS is an operational problem; the RMS into NERIS is a compliance one.
Example department application
Against the Step 1 baseline, and only against it. A measure with nothing to compare it to is a number, not a result.
One caution worth stating directly: nothing here should be read as a claim that moving to NERIS improves any of those measures on its own. Whether a department's reporting got faster, cleaner or more complete depends on its own configuration, training, workflow and data discipline. That is exactly why the baseline has to be local.
Example department application
A forced transition is an unusually good audit of a department's technology, because it touches almost all of it at once. The findings are worth capturing while they are still uncomfortable and specific.
NERIS Public is worth understanding accurately, because it is easy to over-read.
Incident Basics is a national incident-level dataset covering the current year on a trailing 60-day window, with each record carrying incident type, date and time characteristics, location context, actions taken, and basic location type and use. Records are reviewed and scrubbed of sensitive information before release. A separate national layer covers more than 30,000 fire departments and refreshes daily.
That is a substantial change from an annual national release, and it opens up comparison, community risk work and planning that were not practical before. It is not a live feed, and USFA says directly that NERIS data is not intended for operational decision-making. The 60-day trailing window is deliberate. Plan around it rather than against it.
Departments that treated this as a compliance task did the minimum and got a new place to type the same reports. Departments that treated it as a technology adoption discovered which of their integrations nobody documented, which of their data was never as complete as they assumed, and which system they had been paying for and not using.
The change was not optional. What the department learned from it was.
USFA's overview of NERIS: what it is, who is building it, and how it replaces NFIRS as the national fire incident reporting and analytics platform.
Why it matters
The starting point, and the authority. Read this before any vendor's account of what NERIS requires of you.
The transition timetable and the deadlines that went with it, plus USFA's guidance on records retention and exporting incident data out of eNFIRS.
Why it matters
The source for every date in this case study. Its records-retention section is the part departments most often discover too late.
The publicly released NFIRS annual data files on OpenFEMA, what years they cover, and USFA's own cautions about how the data may and may not be used.
Why it matters
Where the historical national data lives now. The disclaimer on this page is worth reading before anyone builds an argument on NFIRS totals.
The open datasets built on NERIS data: what each one contains, how often it refreshes, and the lag on each.
Why it matters
The authoritative description of what the public data actually is, including the 60-day window and the statement that it is not intended for operational decision-making.
The technical material: core and secondary data schemas, the user reference guide, onboarding and post-onboarding checklists, and vendor enrollment guidance.
Why it matters
Where the schemas and the integration detail live. Take these into a vendor conversation rather than accepting a vendor's summary of them.
Nothing here is paid placement. Links are chosen because they are the clearest explanation we could find, and labeled so you know who wrote them.
