A rewrite postmortem is a distinct genre from an incident postmortem, even though the two get filed under the same mental category by many readers. An incident postmortem is written because something broke and the team owes an explanation. A rewrite postmortem is written because a team spent months, sometimes years, replacing a system's language, architecture, or storage layer, and lived to tell about it. That second condition is the problem: only the teams that lived to tell about it get to write the post.
The post only exists because the rewrite shipped
A rewrite that goes well produces a natural artifact: a working system, a set of before-and-after numbers, and a team with the standing to say the investment was worth it. A rewrite that goes badly produces the opposite. It gets scoped down quietly, frozen indefinitely, or reverted after quarters of sunk cost, and none of those outcomes come with an obvious moment to publish. Nobody schedules a blog post for the week a rewrite gets shelved.
The result is a public record heavily skewed toward "rewrites work," even though anyone who has spent time inside a mid-size engineering org has seen at least one rewrite that did not. Failed rewrites are common. They are also nearly invisible in public writing, because admitting one requires a team to describe a multi-quarter effort that produced no shippable outcome, which is a much harder story to tell than a success.
What is usually missing from the success story
Even successful rewrite posts tend to omit the parts of the cost that would make a reader more cautious. The real cost in engineer-months is often understated, because it is measured from the day the rewrite was formally approved rather than from the earlier months spent prototyping, arguing for headroom, or building throwaway proofs of concept that never shipped.
The feature freeze during the rewrite rarely gets its own paragraph, even though it is often the most painful part for the business: a team that spends nine months rewriting a service is a team that spent nine months not building anything customers asked for. And the moment partway through when the team nearly gave up, brought in outside help, or seriously considered reverting, almost never survives into the final draft, because by the time the post is written the ending is already known to be good.
Read timeline claims skeptically
A "six month rewrite" post published two years after the project's kickoff is a useful example of a claim that deserves a second look. Six months may be the length of the final push, the part with a clean before-and-after story, while the real timeline included a year of false starts, an earlier rewrite attempt that was abandoned, or a long stretch where the project was deprioritized and picked back up. A reader who takes the stated duration at face value ends up with a distorted sense of how fast a comparable rewrite might go for their own team.
A useful habit is to check the publication date against any dates mentioned in the post itself, and to treat a gap between them as a signal that the stated timeline is a curated slice rather than the full story.
Weight any single success story accordingly
None of this means rewrite postmortems are useless. The engineering detail inside them, the migration strategy, the dual-write period, the cutover mechanics, is often genuinely instructive. But the absence of failed-rewrite posts in the same genre should push a reader to weight any single success story less heavily than it feels while reading it.
A rewrite that worked for one team, at one scale, with one particular set of constraints, is one data point in a distribution that includes an unknown number of unpublished failures. Reading three or four rewrite postmortems from different companies, rather than treating one as representative, is a reasonable way to correct for a bias the genre cannot correct for on its own.