A replant is one of the most ordinary events in a growing season — a stand fails, comes up thin, or gets taken out by weather or an early pest, and the field gets planted again. It is also the single easiest way to silently corrupt an otherwise good planting record, because the intuitive way to handle it is exactly the wrong one.
The intuitive move is to open the original planting record and correct it — change the date, maybe the seed lot, maybe the variety, so the record reflects what is actually in the ground now. It feels tidy. It is also the mistake, because it erases the fact that a first planting happened at all, and everything that referred to that first planting is now silently pointing at something that, according to the record, never existed.
A replant is a second event, not a correction to the first
The right way to think about a replant is that it did not undo the original planting — it followed it. The seed went in, it failed for some reason, and a second planting happened afterward. Both of those are real, distinct facts about the field’s history, and a planting record exists to capture facts, not to be tidied up into whatever is true as of today.
Treat a replant as a new planting record, with its own date, its own seed lot, and a note referencing the planting it replaces. The original record stays exactly as it was written, because it is still true — that seed really was planted, on that date, and it really did fail. Overwriting it does not make that less true; it just removes the only place that fact was recorded.
Overwriting breaks everything that already pointed at the original
The damage from editing the original record in place is not contained to the planting itself. Anything recorded between the original planting and the replant — a scouting note describing a thin stand, an input applied to try to save it, an observation about what went wrong — was written against the original planting’s date and seed lot. If that record is overwritten with the replant’s details, every one of those earlier entries is now attached to a planting event that, as far as the record shows, happened on a different date with different seed than the notes describe.
This is the same reasoning behind keeping scouting notes tied to a specific planting rather than just a field: the notes are only coherent if the planting they refer to still exists, unaltered, in the record. A replant handled as an overwrite quietly strands every note that came before it.
Beyond the seed lot and the cause, a replant resets the clock every subsequent record depends on. Days-to-maturity, an expected harvest window, and any pre-harvest interval on a later input are all counted from the planting date — and after a replant, the planting date that matters for those calculations is the replant’s date, not the original’s. A record that overwrites the original loses this distinction entirely, leaving every later date calculated from the wrong starting point.
Write down why, not just that
A bare replant record — a new date, a new seed lot, nothing else — captures the fact but loses the lesson. The reason a stand failed is often the single most useful piece of information the whole event produces: a cold snap after planting, a crusting soil that prevented emergence, a seed-borne issue traced to a particular lot, a pest that took the seedlings before they established.
Recording the cause, even briefly, is what turns a replant from an isolated inconvenience into evidence for next year’s decisions — whether that means adjusting planting depth, choosing a different variety, or, if the cause traces back to the seed itself, following up on the seed lot in question. None of that is available later if the record only shows a date changed.
A partial replant needs its own boundary, not just its own date
Replants are frequently partial — a wet corner of a block fails while the rest of the field establishes fine, and only that portion gets replanted. This case is where the temptation to edit the original record is strongest, because most of the field really didn’t change. But the block now genuinely contains two plantings occupying different areas, and a single record, however it is edited, cannot represent that.
The practical answer is to give the replanted portion its own identity — a sub-block, a marked area, or simply a note specifying which part of the field the new entry covers — so that later records, like a scouting note or a harvest lot, can say which planting they actually describe rather than assuming the whole block is uniform. This is the chain that a crop year is built from, and a replant is the event most likely to break a link in it.
The harvest lot inherits whichever version survives
The cost of getting this wrong shows up furthest downstream, at the harvest lot. A harvest lot points back through its planting to the inputs and seed that touched it. If the replant overwrote the original planting, the lot points back to a single, blended version of events that never actually happened as written — a seed lot that was only in the ground for the plants that survived the first attempt, described as though it were the seed for the whole field. A question about that lot months later inherits the same corruption, with no way to detect it from the harvest end of the chain.
Append, always, even when it feels redundant
The discipline this page describes is narrow and easy to state: when a field is replanted, add a new record. Never edit the original planting to reflect the replant, even when the original feels like a mistake now sitting in the log. A record of a planting that failed is not an error to be corrected — it is a true thing that happened, and it belongs in the history exactly as much as the planting that succeeded.
Farm40 treats each planting as its own dated entry rather than a single mutable row per field, so a replant is naturally recorded as an addition rather than an edit, and everything logged against the original planting stays attached to it. The limit: Farm40 will not stop you from editing an existing entry if you go looking for that option — it enforces the shape of a good record, not the habit of using it that way. The decision to append rather than overwrite is still yours to make, every time.
The habit costs seconds at the moment of replanting and saves hours the day someone downstream — a certifier, a buyer, or your own future self reconciling the season — asks a question the overwritten version could never have answered.