The hard part is not the data
Most migration plans budget carefully for moving data and barely at all for moving logic. That is backwards. Data migration is tedious and well understood. Code migration to Marketing Cloud on Core is an architectural re-platform, because the execution model underneath it is different.
Legacy Marketing Cloud Engagement evaluated SSJS and AMPScript at send time, in a context that tolerated fairly heavy work. Core enforces strict platform limits to protect CRM processing. The same logic, ported directly, will not run.
Logic has to move up the funnel
The governing principle of the matrix is that complex scripting must shift earlier — out of send-time rendering and into Flow, Apex Invocables, or Data Cloud batch transforms that run ahead of the send.
A LookupRows() call that resolved a relational lookup at render becomes a Flow Get Records or an Apex SOQL query. But porting it one-for-one usually reintroduces the problem: querying large datasets at send time hits governor limits. The fix is to pre-join the data in Data Cloud so nothing needs looking up at render at all.
Ten categories, each with the trap named
The matrix is organised by operation type rather than by function name, because the mapping is rarely one-to-one. Each row gives the legacy MCE construct, its Salesforce Core equivalent, and — most usefully — the architectural trap that catches teams who translate literally.
Query Activities that ran in Automation Studio map to Data Cloud Batch Transforms. Heavy SSJS becomes an Apex Invocable. CRUD operations split depending on whether they are reads or writes and how much data they touch.
Where nothing equivalent exists
The most valuable rows are the ones that do not resolve cleanly. Some legacy patterns have no Core equivalent, and pretending otherwise produces a migration plan that collapses in build.
The matrix names those explicitly and describes what to do instead — usually a re-architecture rather than a translation. Knowing which of your patterns fall into this category before you scope the project is the difference between an estimate and a guess.
What’s inside
- CRUD and database operations: LookupRows() → Flow Get Records or Apex SOQL
- The governor-limit trap in querying massive datasets at send time
- Pre-joining relational data in Data Cloud instead of at render
- Apex Invocables as the replacement for heavy SSJS
- Data Cloud Batch Transforms for what used to run in a Query Activity
- Every row framed as: legacy MCE, Salesforce Core, then the architectural fix
- Where the direct equivalent simply does not exist, and what to do instead
