A portage is the stretch of a canoe trip where the water ends and you carry everything overland to the next lake. Nobody carries it all in one trip — you’d break something, probably yourself. You stage the loads, make passes, and count the gear at the far end. After years of running migrations and rescues, I’ve stopped pretending the work is anything else, so around here the approach has a name: the portage method.

The four rules of a carry

Inventory before you lift. Before anything moves, everything gets counted: content types, users, files, orders, the weird table someone added in 2016. A migration that starts without an inventory is a portage that starts by throwing gear into the woods. This is why every project here starts as an assessment — the map costs a little, and it’s the cheapest part of the trip.

Carry in passes, not armfuls. Big-bang cutovers fail for the same reason one-trip portages do: too much in your arms, no hand free when you stumble. The method is increments — move a load, verify it, go back for the next — against a live site when needed, so the old system keeps working until the moment the new one provably does.

Count at the far end. The trip isn’t done when you’re tired; it’s done when the gear count at the put-in matches the count at the take-out. Source counts, destination counts, reconciled every pass. “Looks done” and “numbers match” are different claims, and only one of them holds up.

The portage ends. This is the part clients need most. Mid-carry, every project feels endless — the trail is muddy, the load is heavy, and the next lake is a rumor. But a staged carry has a known number of passes, so you always know which trip you’re on and how many remain. Heavy is fine. Uncounted heavy is what breaks teams.

None of this is clever. That’s the point — the method is boring on purpose, because boring survives. The water’s always there on the other side.