The rewrite stalled on a column called status.
The code was not the problem. An inherited Python 2 monolith with money flowing through it, pulled apart service by service: unremarkable work.
Then the new service started answering confidently and wrongly about old records.
Those status values had not meant the same thing across the life of that table. Early rows came from code paths deleted years earlier. Later rows reused some of the same values for a different state. Nothing in the repository recorded the switch, so the only place that history survived was the data itself.
Porting the module turned out to be the cheap half. The backfill is where the time went: I reconstructed era boundaries from the rows, worked out what each legacy value meant inside its own period, then ran old and new side by side against historical records rather than fresh traffic. On fresh traffic the two systems agreed from day one. Agreement on new rows told me nothing.
So the question I now put ahead of every other one before a rewrite has nothing to do with the code: can the new system interpret the oldest data as faithfully as the code that wrote it?
In practice that means inventorying each state field's value set by time window, and treating any value no current code path can still produce as a separate legacy meaning until proven otherwise.
I keep the longer version of this, the full set of questions I run before agreeing to a rewrite, on my blog: https://polycratia.com/c/281aae59
If you are weighing one right now, you probably want to know which of your status values your current code can still write, and what the rest used to mean.