Migrating poultry records to a new system succeeds or fails on three decisions: where the boundary falls, what gets carried across it, and how the first settlement proves the new record is complete. Everything else — which app, which plan, which templates — is secondary to those three. This page is the migration hub: the universal method, the source-system specifics (paper, spreadsheets, notes apps, Excel workbooks, desktop software, generic farm apps), and the verification that closes the migration. It makes no claim that migration is painless; it claims the pain is bounded and predictable if the boundary is respected.
The Three Decisions
| Decision | The Workable Answer | Why It Decides Success |
|---|---|---|
| Where the boundary falls | A new flock placement or the first of a month — never mid-flock | Mid-flock boundaries force dual entry, and dual entry kills the habit before the migration completes |
| What gets carried | Active flock state (seeded), 2-3 flocks of summary numbers (transcribed), finance history (imported via CSV where it exists in rows), everything else stays in the archive | Carrying everything means migrating nothing — the backlog kills the habit too, from the other direction |
| How it is verified | The first settlement compared line-by-line against the new record set | A record set that can settle a flock is complete enough to run the operation on — the only verification that matters |
Source-System Guides
- From paper records — what notebooks hold, what to transcribe vs leave, the read-only cutover cycle.
- From spreadsheets — retiring formulas, moving expense history, keeping the workbook read-only.
- From Excel workbooks — the finance CSV import path, re-pointing summary sheets, archive timing.
- From notes apps — transcribing numbers and leaving prose, closing the app to flock records.
- From desktop software — running the field first, re-pointing reports, office-side import.
- From generic farm apps — the poultry-specific capability check that decides whether to migrate at all.
The Verification Walkthrough
- Week before the boundary: inventory what the current system holds (the source-system guides' tables cover each case); convert cost sheets to the finance CSV template where applicable.
- At the boundary: seed the active flock — placement data, latest weights, recent feed and mortality — so the new record starts from reality, not zero. The digital records guide covers the record types this includes.
- First cycle: run the old system read-only — do not write in it. Reaching for it signals a missing or slow record type; the mobile logging guide covers entry speed in the field.
- At settlement: run the settlement comparison against the new record set. Match, and the migration is done; miss, and the missing record type is named and added before the next placement.
After the Migration
The payoff is not the migration itself — it is that every record after the boundary is structured as it happens, and the computed outputs start working: cost per bird, feed conversion against the feed chart, growth against the growth chart, and the profitability dashboard across flocks. The independent record of truth framing is why the structured record matters at settlement — and why migration day is worth doing right.
Frequently Asked Questions
How long does a poultry record migration take?
The method's timeline is one full grow-out cycle: seed at the boundary, run the old system read-only for one flock, verify at that flock's settlement. What varies is how much finance history needs converting to the CSV template before the boundary — days for most operations, not weeks.
Do I have to import my entire record history?
No — and trying to is the most common way migrations fail. Active flock state gets seeded, two to three flocks of summary numbers get transcribed, finance history imports where it exists in rows, and older notebooks stay as the paper archive. The backup guide covers preserving the archive properly.
What if the old system has data the new one cannot hold?
Keep the old system (or its export) read-only as the archive for that data, and confirm the data you still actively decide on is covered. A migration does not require the new system to reproduce every historical table — it requires the operational record to be complete going forward.
- 2026-10-06: Comprehensive rewrite as the migration cluster hub — three-decision framework, source-system guide index, verification walkthrough, and verified capability claims only — replacing the earlier version with fabricated first-person claims.
- Earlier version: first-person narrative about migrating records.