Marketo to AJO: not just another lift-and-shift

Quick lesson from a recent Marketo-AJO project: Marketo is program/campaign-centric whereas AJO is event/journey-centric. This sounds obvious, but it changes the schema design, segmentation, and journey logic. This is not a mere lift-and-shift setup. 

The two main things aren’t the journeys themselves. These are schema design and identity resolution. Both are harder than they look.

XDM Schema Design

In Marketo, the data model is flat and permissive - custom fields can be added without touching anything else. In AEP, the schema is formal and more structured that every journey, segment, and destination downstream depends on.

Few things that matter in practice:

• Schema classes come first: AEP has 2 main core classes - XDM Individual Profile (attributes like name, email, title, etc.) and XDM Experience Event (timestamped events like website visits, form fill outs, etc.). Every Marketo field needs to be sorted into one of these buckets before building anything else.
• Some Marketo fields have no native XDM equivalent: Adobe’s standard field groups (Demographics details, Contact details, etc.) cover common attributes. Anything Marketo  specific (lead score, lifecycle stage, etc.) has no XDM equivalent. So, you’ll need to build custom field groups for these. 
• XDM Individual Profile vs XDM Experience Event: XDM Individual Profile fields are static and get overwritten. XDM Experience Event stores timestamped data. So, for data where history is required, it’s necessary to use XDM Experience Event.

Identity Resolution

This is conceptually the biggest departure from how Marketo thinks about a “Person/Record”. 

• Marketo dedupes primarily on email address: One email = one record. If the same person uses a different email address next time, a new record will be created in Marketo. 
• AEP thinks in identity graphs, not single records: This means a profile can have several emails. Every identifier (email, CRM ID, cookie ID, Loyalty ID) is a namespace, and AEP’s Identity Service stitches these together into a graph representing one person across multiple touchpoints. 
• The anonymous to known transition: In Marketo, an anonymous website visitor becomes “known” the moment they filled a form and munchkin tracking reassigns their history to the new lead record. In AEP, this needs to be explicitly configured through identity stitching rules tied to the Web SDK implementation - it doesn’t happen automatically just because someone filled a form.  

This is by no means the full picture - migrations like this surface edge cases you don’t anticipate. I’d genuinely like to hear what caught you off guard, what you’d add to this list.