A martech migration is not only a technical platform move. It changes how marketing teams plan work, trust data and keep campaigns moving.
I have worked on a significant Adobe Campaign Standard to Salesforce Marketing Cloud migration for a worldwide brand. The confidential details are not mine to publish, but the delivery lessons are portable.
It is tempting to define the work as a list of assets to rebuild: templates, automations, journeys, data flows, documentation. That list matters, but it is not enough. The real change is how people request work, test changes, approve campaigns, handle incidents and understand what the new platform is doing.
That is why I like migration plans that separate technical conversion from operational adoption. The first asks, “Can the new system do this?” The second asks, “Can the team reliably work this way next month?”
Campaign calendars do not pause because the platform is being replaced. If business-as-usual delivery is treated as background noise, the migration team will constantly be surprised by urgent production needs.
The better approach is to make business-as-usual work visible in the plan. Keep capacity for production support, campaign QA, stakeholder questions and documentation updates. A migration plan that ignores day-to-day marketing work is usually too optimistic.
Documentation is often framed as cleanup after delivery. In a migration, it is part of delivery. It gives the receiving team a way to understand decisions, troubleshoot issues and continue improving the setup after the project team moves on.
The most useful documentation is not a giant manual. It is a set of living artifacts: naming conventions, data assumptions, known limitations, QA checklists, ownership maps and escalation paths.
Many technical issues start as alignment gaps. One team assumes a field means one thing; another team uses it differently. One stakeholder approves a journey; another later challenges the customer experience. One person knows a workaround; the rest of the team does not.
Good project management reduces those gaps early. I try to keep assumptions visible and repeat them until they are boring. Boring alignment is cheaper than late rework.
A migration is not finished when the new platform can send messages. It is finished when the team can operate, maintain and improve the platform with confidence.
That changes the definition of done. A migrated journey should include the supporting process: who owns it, how it is tested, how changes are requested, what data it depends on and what happens if something breaks.
For Salesforce Marketing Cloud migrations, the technical build and the human operating model have to move together. If one gets ahead of the other, the project slows down later.