Rebuilding exactly what exists sounds like the disciplined option. In practice it imports every workaround the old platform forced on you, and calls them requirements.
Every migration reaches a moment where somebody says the reassuring thing: let us rebuild what we have, like for like, and improve it later. It sounds like risk management. It is usually the most expensive sentence in the project.
Marketing setups accumulate. Workarounds for limits the old platform had, campaigns built for a launch that finished three years ago, fields somebody added for a report nobody runs. None of it was designed as a whole; it arrived one decision at a time.
Rebuilding all of it treats accidents of history as intent. Worse, it hides them — once a workaround is rebuilt deliberately in a new system, it looks like a considered choice, and the next person will assume there was a reason.
The useful question is not what the old system does. It is what the business needs the new system to do, which is a shorter list almost every time.
Opinions about what matters are unreliable, and stakeholders defend things they have not used in two years. Usage data settles it: when was each journey last triggered, each template last sent, each field last populated.
That inventory is uncomfortable and fast to produce, and it consistently finds automations that have not fired since before the current team joined.
Give every item an owner and a last-used date, then make keeping something a decision somebody signs rather than the default.
After go-live the team is absorbed by stabilisation, then by the campaigns that were deferred during the freeze, then by the next thing. The rationalisation window closes quietly.
During the migration everything is already open: the data is being mapped, the journeys are being rebuilt, the documentation is being written. Cleaning up costs a fraction of what it costs later.
Deferring means paying to rebuild assets you already intended to delete, then paying again to delete them.
This is not an argument for redesigning everything under cover of a platform change, which is its own well-known way to miss a date.
Anything load-bearing should cross over faithfully and be verified rather than reconsidered: suppression rules, consent logic, contractual or regulatory constraints, and the handful of automations the business genuinely runs on.
The distinction worth holding is between what is load-bearing and what is merely habitual. The first gets carried across carefully. The second gets a decision.
Every keep, drop or redesign call should be written down with who made it and when. Not for ceremony — because it will be questioned mid-build, usually by somebody who was not in the room.
Without that record the conversation restarts from zero at the least convenient moment, and the default answer under time pressure is always to rebuild whatever was there.
Scope the migration against what the business needs next year, not against an inventory of what the old platform happens to contain. Then write down every keep-or-drop decision with a name and a date, because you will be asked to justify them.