A migration is the rare moment when you can hand yourself a system that costs less to run and less to maintain for years, and the price is only a few days of judgment up front. Most migrations throw that moment away. They start from one question, how do we get everything across, and end up paying real money to carry forward weight that was never worth keeping. The better question gives you the lighter system instead: what should not move at all?
Here is why the default question costs you. When a business moves off an old CRM, a tangled automation platform, or a data store that has outgrown itself, the planning optimizes for faithful reproduction. The new system should behave like the old one, only on better infrastructure. So the mess comes along. Dead fields come along. Duplicate logic comes along. The workaround somebody added in 2022 to patch a bug that no longer exists comes along, because nobody remembers it is a workaround. The destination is newer, but the system inside it is the same weight it always was, and that weight is what you pay to maintain every month after.
Ask "what should not move at all?" first, and the migration stops being a copy operation and becomes an editing decision. What arrives on the other side is lighter, correct, and maintainable, not just relocated, and it stays cheaper to run because the reasons it used to break never made the trip. This article makes the case for that reframe through a roughly 300-node automation rebuilt rather than ported.
Move Everything Across, and You Pay Twice
The default question costs you twice: once in migration effort to carry every artifact over, and then every month after in the bill to keep that artifact alive. You pay migration cost to preserve maintenance cost, on every line item at once, because the default never paused to ask whether the line item should exist. That is the trade you sign up for when the plan optimizes for completeness, and completeness is the wrong target. A migration scored on "did everything come across" rewards carrying forward every artifact regardless of whether it still earns its place.
The reason this bill is so large is sediment. Consider what accumulates in a system over a few years of real use. A CRM picks up custom fields one person needed once and nobody has populated since. An automation platform collects branches that fire on conditions that no longer occur. A data store holds columns renamed in practice but never in schema, so the old name lingers with stale values. None of this is anyone's fault. It is the natural sediment of a system doing real work while priorities shifted underneath it.
A faithful migration treats all of that sediment as cargo. It writes mapping rules for fields nobody reads, rebuilds logic nobody triggers, and validates data nobody trusts. The effort is real and the result is a heavier system you keep paying for. The alternative is not recklessness. It is deciding, deliberately, that the migration is the one moment when removal is cheap, because nothing downstream depends on the old structure yet.
Editing Beats Copying, and the System Ends Smaller
Treat the migration as editing rather than copying, and the system that arrives is smaller without losing anything that mattered, because every element had to earn its place instead of riding along. The mechanism is a single flip: every element becomes a question, not a given. Not "how do we move this field" but "does this field deserve to exist in the new system at all."
An editing pass asks the questions an editor asks of a manuscript. Is this doing work, or is it here because it was here? Would a reader miss it if it vanished? Applied to a CRM, that becomes: which fields actually drive a decision or a message, and which just occupy space. Applied to an automation, it becomes: which branches have fired in the last year, and which are theoretical paths the data never takes.
The reframe matters because the economics flip. Under "copy everything," every element is presumed worth keeping and the burden is on you to justify deletion, which almost never happens under deadline. Under "edit then move," every element is presumed disposable and the burden is on the element to justify inclusion. The same migration, viewed through the second lens, ends smaller. Not because anything important was lost, but because the things that survived had to earn the trip.
This is also where a migration stops being purely technical work. Deciding what should not move is a judgment about how the business actually runs, which only a person close to the operation can make. Tooling shows you which fields are empty and which branches never fire. It cannot tell you which of the active ones still matter. That call stays with someone who knows the work, the same boundary that holds in any well-built system: the machine surfaces the evidence, the human makes the irreversible cut. The reasoning behind keeping that boundary deliberate is covered in when not to use AI in an AI system.
A Rebuild That Did More While Getting Dramatically Smaller
On one real system, asking what should not move produced a result that did more than the original while being dramatically smaller to read and reason about: seven sequential pipeline stages in place of roughly 300 nodes, including a scoring step the old pipeline had no equivalent for. The rest of this section traces that payoff back to its cause.
The system that earned it was a legacy automation grown to roughly 300 nodes spread across four disconnected tools: a browser-automation tool running scripts, a workflow tool moving data between systems, a document workspace holding notes, and a spreadsheet tracking status. Each tool fed the next in a strict sequence. The instinct on a system that size is to map it node for node into something more modern and call it a migration. The decision instead was to rebuild, treating the existing nodes as a description of intent rather than a specification to reproduce. The question for each piece was not "how do we recreate this node" but "what is this node trying to accomplish, and is that still the right thing to do at all."
Two things became obvious once the work was framed that way. First, a large share of the node count existed only to shuttle data between the four tools. Those nodes accomplished nothing for the business. They were translation overhead, the cost of four systems pretending to be one. Collapse the four tools into one platform and that entire category of node disappears. Second, several long branches handled edge cases the data had stopped producing, or that a person was already catching by eye. Those branches were carrying forward a past state of the world.
That is how a system gets smaller while doing more. The reduction was the byproduct of asking what should not move, and acting on the answer.
A Smaller System Breaks Less Often
The lighter system does not just cost less to maintain, it fails less, which means fewer mornings spent finding out your numbers were wrong. Cutting node count improves reliability because in the old four-tool pipeline every one of the roughly 300 nodes was a place the chain could break, and the tools were strictly sequential. The first tool fed the second, which fed the third, which fed the fourth. Break any early link and everything downstream went stale without warning. The numbers your team was making decisions from were wrong, and nobody knew.
The most common break was mundane. The browser-automation scripts targeted external sites that changed their layouts without notice. A site moved a field or renamed an element, and the script pointing at the old location quietly returned nothing. The next tool received empty data and passed it along. The spreadsheet showed information that no longer reflected reality. Nobody was alerted. The failure stayed silent until someone noticed the numbers looked wrong, then traced backward through four tools to find the one broken selector.
After the rebuild, that failure surface shrank to almost nothing. With the four tools collapsed into one platform, there were no inter-tool handoffs left to fail. The per-site fragility was isolated into a single configuration object per site, so a layout change touched one file instead of cascading through a chain. The system that arrived was lighter to maintain precisely because the editing pass had removed the structural reasons it used to break. A smaller system has fewer failure points by definition, and the failure points it keeps are the ones that map to real, irreducible complexity rather than to accidental plumbing.
This is the connection the default migration question misses. Carrying forward every node carries forward every failure point. The system that asks what should not move ends up not only lighter to read but steadier in production, because the things most likely to break were often the things that should never have made the trip. The distinction between a system that survives a real workload and one that only looks finished is explored further in production agent system vs demo.
Trade a Few Days of Judgment for Years of a Lighter System
This sequence trades a few days of judgment up front for a system that is lighter to maintain for years, the best return available anywhere in a migration budget. The mechanism is front-loading judgment before any data moves: slower at the start, faster across the whole project. Each step below exists to answer one question for you: what can the operation stop carrying? Here is how that runs.
Start with usage evidence, not the schema. Before mapping a single field, pull the record of what the current system actually uses: which fields get populated and read, which branches have fired in a recent window, which columns appear in real queries. This produces an inventory split into two piles, load-bearing and inert. The inert pile is your candidate list for what should not move.
Then make the cut a decision, not an omission. Walk the inert pile with someone who knows the operation and mark each item: confirmed dead, or quietly important. Empty fields are usually dead. A rarely fired branch might be the one that handles year-end, so it is quietly important. The point is that removal becomes a recorded choice with a reason attached, which is what separates editing from data loss.
Rebuild the survivors around current intent, not past structure. The elements that earn the trip should fit how the business runs now, not the shape the old tool forced on them. This is where collapsing redundant tools and dropping translation overhead happens naturally, because you are building for the present rather than reproducing the past. Run old and new in parallel briefly to confirm the survivors cover real cases, and keep the inventory of what was cut, so any surprise has a documented place to be found rather than a mystery to rediscover.
The whole sequence costs more thinking up front and far less carrying afterward. The system that comes out the other side is smaller to hold in your head and steadier to run, which is exactly the system you wanted and rarely get from a migration.
Migration Is the One Cheap Moment to Get Lighter
A system migration is usually framed as a risk to be survived: get everything across without losing anything, then breathe. That framing wastes the single best opportunity a system ever gets to shed weight. Removal is expensive in a running system, because everything downstream might depend on the thing you want to cut. During a migration, before the new system has dependents, removal is nearly free.
The transferable principle is small and it changes the entire shape of the work. A migration is not a copy operation. It is an editing decision. The question that produces a good outcome is not "how do we move everything across," it is "what should not move at all," and the discipline is to answer it deliberately rather than let the default carry the sediment forward by inertia.
A system that arrives lighter, correct, and maintainable is not the lucky result of a clean migration. It is the predictable result of treating the move as the moment to decide what the system should no longer be.
Provenance: this article was produced by the same multi-agent system its companion pieces describe. The angle began as a validated observation about migration questions, was checked against an anonymized rebuild of a roughly 300-node automation drawn from real project records, and was written by the writer agent in a Claude Code workspace, briefed by the founder. No client or niche is named, and every node count cited is a first-party figure from the project it describes.
If a migration is on your roadmap, a 30-minute call covers how to scope what moves, what gets rebuilt, and what gets left behind for your specific systems.