When most people picture a CRM migration, they picture engineers. Code being written. Workflows being rebuilt. The technical work of moving from one platform to another.

That's real. But it's not where most of the time goes.

Before a single journey gets rebuilt in Braze, someone has to understand every journey that already exists in Iterable. Someone has to document them. Audit the catalogs they depend on. Convert the template logic. Organize months of meeting notes into something the next person can actually find and use.

Hundreds of journeys to inventory. Campaigns, templates, snippets, and catalogs — each one needing analysis. Meeting artifacts scattered across recordings, transcripts, and everyone's personal notes. Years of business logic that lived in people's heads, not in any documentation.

This is the hidden cost of migration. Nobody puts it on a timeline slide. It doesn't have a clean deliverable. It's just the slow, manual, grinding work that has to get done before the real work can start — and it can consume hundreds of hours if you let it.

I decided not to let it.

What if AI did the busy work entirely?

Not assisted it. Not made it a little faster. What if AI just did it — connected to the actual systems, read the live data, wrote the documentation, organized the artifacts — while the team focused on the decisions only humans could make?

That question led to something I hadn't originally planned to build: not one AI workflow, but a whole collection of them. Each one targeting a different piece of the pre-migration work. Each one designed to be reused — not just on this migration, but on every one that came after it.

The goal was never just to save time on this project. It was to build capabilities the team could keep using. That's a different objective, and it changes how you design everything.

The principle behind the migration workflows

Six workflows. One shift in how the work got done.

Using Claude connected to Iterable, Confluence, Google Drive, and Gmail, I built a library of AI workflows that handled the repeatable operational work automatically. Here's what each one did — and why it mattered.

The AI workflow library
📄
Journey documentation — automated into Confluence Instead of an analyst spending two to four hours manually reviewing each journey and logging it into a template, Claude read the live Iterable journeys directly and wrote the documentation automatically — same structure every time, no omissions. What used to take hours took minutes.
🗂️
Catalog audit — all 42, generated automatically Braze uses catalogs to personalize messages with product and content data. Before a single one could be rebuilt, we needed to know exactly what catalogs existed in Iterable and what each one contained. Claude generated a complete audit across all 42 — something that would have required engineering involvement to do manually.
🔄
Template conversion — Handlebars to Liquid Iterable uses Handlebars templating. Braze uses Liquid. Every template had to be translated. Claude did the conversion, giving developers AI-generated starting points instead of blank files. The engineering team still reviewed and refined — but they weren't starting from scratch.
📁
HTML template archiving — organized into Drive Existing HTML templates needed to be preserved and organized before the migration moved forward. Claude archived them into structured Google Drive folders automatically — no manual sorting, no files lost in someone's inbox.
🌐
Localization catalog reformatting — Braze-compatible imports Localization files from Iterable weren't in the format Braze expected. Claude reformatted them into Braze-compatible imports, removing a data transformation step that would otherwise have required manual work or custom scripting.
🧠
Project knowledge base — months of meetings, made searchable Every migration accumulates context in meetings — decisions made, rationale explained, directions changed. That context usually lives in recordings nobody re-watches and transcripts nobody reads. Claude consolidated them into a searchable knowledge base. The next person who joined the project didn't have to ask what had already been decided.

The shift nobody expected

The time savings were real. Journey documentation that used to take two to four hours took minutes. The catalog audit happened automatically instead of requiring an engineering sprint. Template conversions gave developers a head start instead of a blank page.

But that's not what changed the team.

What changed the team was realizing that these workflows didn't go away when we finished a journey. They were reusable. Every capability we built could be applied to the next journey, the next campaign, the next migration.

That's a different relationship with AI than most teams have. Most teams use AI for isolated tasks — write this email, summarize this doc, answer this question. What we built was an operating layer. A set of capabilities that became part of how the migration program ran, not a tool people reached for occasionally.

The thing that stuck with me

There's a moment in a project when the team stops asking "can AI help with this?" and starts asking "which workflow handles this?" That shift — from AI as a tool to AI as an operating model — is where the real value lives. It's also a lot harder to get to than people realize.

What it looked like before and after

The clearest way I can show what changed is side by side:

How migration prep worked before
  • Analysts spent 2–4 hours documenting each journey manually
  • Documentation quality varied based on who did it and when
  • Catalog audit required engineering involvement to run
  • Template conversion started from a blank file every time
  • Meeting context scattered across recordings, transcripts, and personal notes
  • New team members had to ask what had already been decided
  • Every workflow built once and abandoned when the task was done
How migration prep worked after
  • Journey documentation completed in minutes, same structure every time
  • Consistent output regardless of who initiated it
  • All 42 catalogs audited automatically, dependencies surfaced
  • Developers received AI-generated template conversions as a starting point
  • Months of project knowledge consolidated into a searchable base
  • Any team member could find prior decisions without asking
  • Every workflow reusable on the next journey, campaign, or migration

What this means beyond one migration

I've been doing enterprise marketing technology work for more than 20 years. Migrations are a constant. The platforms change — it used to be Eloqua and ExactTarget, now it's Braze and Klaviyo and whatever comes next — but the pre-migration work is always the same. The inventory, the documentation, the auditing, the knowledge management. It's always manual. It always takes longer than anyone budgeted.

It doesn't have to.

The workflows we built for this migration aren't specific to Iterable or Braze. The pattern is repeatable: connect AI to your source systems, define the structure you need the output to follow, let it do the inventory and documentation work, and build the resulting capabilities into how your team operates — not just how they finish this one project.

The biggest opportunity with AI in enterprise work isn't replacing people. It's removing the operational layer of work that slows great teams down — the documentation, the data transformation, the knowledge management — so they can spend their time on the decisions and the strategy that actually require human judgment.

That's the kind of change that outlasts any individual migration.

Working on a migration?

Let's talk about what's possible

Whether you're in the middle of a platform migration or planning one, I'd love to talk through where AI could take the operational work off your team's plate. Not as a pitch — as a conversation between people who've both done this work and know how much of it doesn't have to be as hard as it is.

See more of my work Let's connect