The Week Phoenix Had No Crime

The last record from the Phoenix Police Department's old records system is timestamped 11:55 p.m. on September 2, 2025. The next record in the city's public crime file is timestamped midnight on September 9. Between them are six days with no crime at all. No thefts, no stolen cars, no assaults, in a file that logged 805 incidents across the same six days a year earlier.

Nothing happened to Phoenix that week. Something happened to its software. According to a January 2026 city update, “a new records management system (Motorola P1 RMS) launched September 9, 2025,” and the public file carries the seam in seven of its eight columns.

This post is about how to see a seam like that from the data alone. You will probably have to. The city page that is supposed to explain the transition returned a 404 when we checked it on September 14, 2026.

The file

Phoenix publishes one CSV of crime incidents on its open data portal. It has eight columns and 624,147 rows. The description says it runs from November 1st, 2015 through December 31, 2025, and lists nine offense types (homicides, rapes, robberies, aggravated assaults, burglaries, thefts, motor vehicle thefts, arsons, and drug offenses) “based on the primary offense listed for each incident.” It was last updated February 2, 2026.

We downloaded all of it. Here are two theft records, one from each side of September.

INC NUMBER        OCCURRED ON             CATEGORY        ZIP    PREMISE TYPE
202500001193446   08/15/2025  00:00       LARCENY-THEFT   85006  BAR / LOUNG / NIGHT CLUB
202501654794      11/15/2025   2:55:32PM  LARCENY-THEFT   85051  DEPARTMENT / DISCOUNT STORE

Same city, same column headers, same kind of crime. Almost nothing else about those two lines agrees.

Where the seam shows

First, a confession. Our first pass at this file counted records by month by reading the date string at fixed character positions. The old system writes 08/15/2025. The new one writes 12/7/2025, with no leading zero. Every new-system record with a one-digit day or month fell out of the query without an error, and our first count had Phoenix's fourth quarter down 15%. The real file says something else entirely, and we will get to it.

Here is everything we found that changed at the cutover.

Some of these are probably improvements. A timestamp with seconds is likely more honest than one rounded to the hour, and fewer midnight placeholders is good news if you read our piece on the busiest minute in Los Angeles. We can't tell from the file which changes are better data and which are just different data.

That's fine. Crime doesn't change the width of an incident number.

September looks fine

From January through August 2025, Phoenix's file ran 14.1% below the same months of 2024: 30,684 records against 35,726. September 2025 came in at 3,814 against 4,237. Down 10.0%. On a chart, that is an ordinary month, a little softer than trend.

It is missing six days. It also contains 959 simple assaults, a category that could not have appeared in September 2024 because the file didn't carry it. The two errors are about the same size and point in opposite directions. They cancel, and the month looks normal.

Compare only September 9 through 30, without simple assault, and the drop is 16.4%. That is roughly where the year had been running.

The fourth quarter is worse. Count every row and crime in Phoenix rose 19.2% year over year. Drop the new category and it fell 12.2%, close to trend. Both are true statements about the same CSV. The headline you get depends on whether your pipeline noticed that a column started holding a new value.

The categories moved too

Set simple assault aside and individual offenses still stepped off their own trend lines, all in the same quarter.

Theft and aggravated assault held their course. Burglary flattened and robbery reversed. Arson nearly vanished: about fifty records a month through August, then 16, 7, and 9 in October, November, and December. (Homicide went from 36 to 47. At counts that small we would not read it in either direction, for the reasons in our post on small numbers.)

Some of this may be real. We think most of it isn't, and the file gives a reason. Every row is filed under a primary offense. Phoenix's own crime statistics page explains that under NIBRS, crimes against persons are counted “with all crimes that occurred in an incident reported, rather than only the most severe.” When a records system stops ranking offenses inside an incident, whatever export picks the “primary” one has to be rebuilt. An arson that happens alongside another offense can land in either column, depending on how. The file doesn't say how.

Every migration leaves one

Phoenix is our example because Phoenix did something generous. It kept publishing the old file across the cutover, so both sides of the seam sit in one download. Most places don't give you that.

Baltimore's police department still carries a notice on its open data page that Part 1 crime data “have been impacted starting in May, 2021 when the new system went online.” Los Angeles moved to a NIBRS-aligned system on March 7, 2024, and we wrote at length about the reporting gap that followed. We have watched records migrations do this to feeds we ingest, and it never announces itself as a migration. It announces itself as a trend.

Andrew Wheeler's recent notes on US crime trends split city series into trend, seasonal, and residual parts, and one of the things his residuals turn up is a reporting problem (Bismarck, May 2025) rather than a crime pattern. That is the right instinct. A break in a series is a data event until somebody shows otherwise.

The Phoenix file also stops. The department ended reporting to the FBI's summary system in January 2026, earned NIBRS certification on January 8, and posts monthly NIBRS overview PDFs for 2026. The incident-level CSV ends at December 31, 2025. We searched the portal for a successor file and didn't find one.

Run it yourself

The new system left one gift. Every timestamp it writes ends in AM or PM, and the old system never wrote either. A single LIKE clause splits the file at the seam. This returns the new-system records by offense:

curl -G "https://www.phoenixopendata.com/api/3/action/datastore_search_sql" \
  --data-urlencode "sql=SELECT \"UCR CRIME CATEGORY\", count(*) FROM \"0ce3411a-2fc6-4302-a33f-167f68608a20\" WHERE \"OCCURRED ON\" LIKE '%M' GROUP BY 1 ORDER BY 2 DESC"

And this counts records from September 3 through 8, 2025, in either date format. It returns zero. Change the pattern to '09/0[3-8]/2024%' and it returns 805.

curl -G "https://www.phoenixopendata.com/api/3/action/datastore_search_sql" \
  --data-urlencode "sql=SELECT count(*) FROM \"0ce3411a-2fc6-4302-a33f-167f68608a20\" WHERE \"OCCURRED ON\" SIMILAR TO '(09/0[3-8]|9/[3-8])/2025%'"

We skipped the per-column profiling code here because it is thirty lines of counting nulls, and you would write it differently anyway. The idea is in the list below.

Seven checks for a records migration

None of these need a model. They need a habit of looking at columns and not just rows.

1. Profile every column on every refresh. Null rate, distinct values, string length, format. A migration moves several of them at once. Crime moves none of them.
2. Parse dates against an explicit list of formats, and fail loudly. A row that matches no format is an alarm, not a skip. We relearned this one on this file.
3. Treat a new category as a schema change. Hold it out of totals and trends until you have decided what it maps to, and out of year-over-year comparisons until there is a year to compare it to.
4. Normalize labels before you group. DRUG OFFENSE and DRUG OFFENSES are one crime. We have written about why taxonomy mapping is most of the work.
5. Re-geocode instead of trusting a derived field.The ZIP went blank. The 100-block address didn't. If you have the address, the geocoding is yours to do.
6. Put the break date in the data.If you serve counts, serve the date the source changed systems right next to them, so the next person's chart gets its vertical line without rediscovering it.
7. Compare like with like across the seam, and say what you left out. Same days, same categories, one sentence explaining both. If you can't build that comparison, don't publish one.

Six days

People in Phoenix presumably did not stop calling the police between September 3 and September 8, 2025. Whatever they reported that week is somewhere, or nowhere, and the public file doesn't say which.

The file's description still says it covers crime incidents from November 1st, 2015 forward through December 31, 2025. It does. It just takes six days off.