Fixing Production Data in Rails: Lessons from a 6,000-Row Backfill

Fixing a bug in production is usually straightforward. But what happens when the data in the database itself is broken? That’s when things get tricky. I learned this when a routine deploy quietly broke confirmed_at on our Order records. By the time anyone noticed, around 6,000 rows were affected — and dashboards, emails, and downstream services all depended on that field. The two-line code fix shipped in minutes, but the data backfill required a lot more thought. The First Naive Attempt Once we understood the scope of the problem, the first instinct was obvious: fix it fast. Most Rails developers will reach for one of two things here — a quick one-liner in the console, or a small migration that updates the data directly. Something like this: Order . where ( confirmed_at: nil , status: "confirmed" ) . update_all ( confirmed_at: Time . current ) Note: In reality, determining the correct value for confirmed_at was more complicated — we had to derive it from related records and business lo