A Field Guide to Agentic CMS Migration

First off, let’s acknowledge that calling anything a guide to anything in the world of Agentic AI is presumptuous at best. The capabilities of Agentic AI are constantly changing and improving, so what I outline here today will likely change, but I believe it should be relevant to future improvements as well—if anything, it should just get easier.

That said, this guide is based on what I’ve observed working with agentic migration workflows in practice.

The principles below are broadly applicable, but the workflow assumes an agent that can inspect the destination CMS, retain reusable migration instructions or skills, execute migrations in parallel, and evaluate its output against a QA checklist.

A Brief Overview of Standard CMS Migrations

If you’ve ever migrated your Content Management System before—whether from AEM 6.x to AEM as a Cloud Service, or Sitecore to Contentful, or any other combination—you know it’s a miserable experience that can take many months to years depending on the complexity and size of your portfolio of pages and sites to be migrated.

Until very recently, a CMS migration meant countless hours, across teams of people, copying and pasting, adding images to your DAM… followed by countless more hours spent in QA. Oftentimes, those QA misses resulted in submitting a ticket back to authors who would then have to go back, when their schedule allowed, to correct any updates… adding even more time to an already maddeningly long process.

Agentic migration doesn’t eliminate the migration bottleneck. It moves it. Page production becomes dramatically faster, which makes quality definitions, agent calibration, destination readiness, and human QA more important—not less.

Enter the Agents

And then came Agentic migration, doing exactly what AI is best at: taking the mind-numbing, tedious work that no human was ever excited to do, and automating it. Suddenly, all you need to do is point the agent at your new CMS and the appropriate template destination, give it access to the source page, and let the agent run while you plan out the next batch and maybe talk about last night’s Bears game over a cup of coffee.

But agents, like the humans running migrations before them, need to understand what they’re doing, what’s expected of them and what “good” looks like… and they can sometimes mess up.

So, how do we set ourselves up for success?

Your Agentic Migration Plan

Preface & Pre-Reqs

Before we get into how to really dial this in for the best results, let me clear out some basic assumptions that need to be in place:

1. You've already defined what pages are being migrated.
2. You've already identified and connected your destination CMS to your agent.
3. The destination content models and primary templates are sufficiently stable.
4. Source pages have been grouped into template or page families.
5. A representative set of pages has been selected for calibration.
6. The agent has least-privilege access and cannot accidentally publish to production.
7. The team has agreed on what “Ready” means.
8. A QA checklist and human approval owner exist.
9. Asset, locale, metadata, redirect, and publishing strategies have been decided.
10. Batch logging exists: source URL, destination entry, skill version, run time, QA result, and remediation history.

Getting Started

You’re in! The CMS is connected to your agent and you see the task before you. Whether it’s a small job of a few hundred pages or a massive, complex undertaking spanning dozens of brands and thousands of pages, you have your plan for what pages are your first priority and what comes next.

Before we get much further, we need to do what is probably the most important, and most easily overlooked, step: defining success.

Define Success

Obviously, the goal is always 100%. But that’s an end-state goal. Even human-executed migrations, that old copy/paste head-on-desk process, aren’t going to hit 100% before they hit QA and many final passes from your CMS Authors to make final touches.

We often expect AI to be perfect and so anything south of 100% can be viewed as a failure. But AI is still fallible. We should expect great things, yes, but we should be reasonable about what defines greatness—especially in the context of the countless hours being saved in the process.

As a starting point, I like 85% as an initial calibration target. Not because 85% is some universal industry standard, but because it is high enough to expose whether the system is genuinely reducing human work while leaving room for early iteration.

And of course, automation completeness does not necessarily equal content completion and go-live readiness. So it’s valuable to have two clear sets of criteria:

Use 85% as an initial calibration threshold, not a release threshold. A page can score 95% overall and still be unpublishable if the missing 5% is the legal disclaimer, the primary CTA, or the submit button. This is also where it’s valuable to understand what the agent can affect—content—and what it can’t, like component availability or site structure.

Once the agent clears that calibration threshold consistently, the remaining work should increasingly shift from broad remediation to targeted exception handling and polish. The point is not that humans are responsible for the final 15% of every page; it is that the agent should be doing the overwhelming majority of the repeatable work before a human ever touches it.

Okay, so now you have an attainable and agreed-upon quality bar goal. At this point, you probably don’t have any idea how much of a win that already is and you’re ready to get started.

But before you dive in, it’s time to train your agent on your new CMS.

Onboarding Your Agent

Before you bring in even your first page, be sure to tell your agent to scan the new destination CMS. This should be a relatively light first step and can be as simple as a basic prompt. These are real prompts I’ve used in practice, not cleaned-up examples written after the fact:

If you’re working with a sufficiently advanced model, you can likely use this to start building out a new Migration skill that will help improve results moving forward:

Coming out of that, you’ll likely get some good information about what your Agent found.

What matters most isn’t the inventory the agent returns to you. It’s that the agent now has that information available as context. Like onboarding any new hire, your agent needs to understand the environment it is expected to navigate and work in.

Just remember: an agent scales whatever you teach it. Good mappings and bad ones alike, so always pay attention to what you’re training your Agent to do.

Calibrate on a Golden Page

Now it’s getting interesting. Your Agent has the context. But no migration has ever been judged on its ability to understand context. What matters is the Agent’s ability to navigate and understand that context sufficiently.

You’re probably wanting to dive in with your first massive batch of 100 pages. But hold off. Your agent is still in training.

Start with one page. Just one. Here’s a prompt I recently used for this purpose:

Once that’s done, check it out. Find the gaps. Maybe the Agent picked the wrong Component, maybe it missed or misformatted a section, whatever. Then go back and prompt the Agent to fix those sections, clear the errors, and get it up as close to perfect as possible—our 85% target doesn’t matter here, we’re going for as close to 100% as possible in this exercise.

Once you’re happy with the page, prompt your agent to update its skill.

If you have, as I’d recommend, a QA Checklist, you should also train your Agent on that so it knows the expectations and can provide a page-by-page breakdown of how the page performs against that list.

One important caution here: treat updates to your Migration skill like changes to production code. Keep versions, understand what changed, and occasionally rerun a few previously approved pages after meaningful updates. A lesson learned from one unusual page can become a bad global rule just as easily as a good one. The agent scales whatever you teach it—so regression testing matters.

Expand Your Calibration Set

Okay, we now believe our Agent should have a solid understanding of the CMS and our expectations for how it should be working. But we don’t want to dive into the deep end quite yet. Let’s pick 5–10 pages that match that same template style and bring those in.

Same thing: once those are done, go through each and give it a quality QA, working with the agent to dial in as close to 100% as possible, and then ask the Agent to update your skill. Because the pages can run in parallel rather than sequentially, the benefits are already starting to compound.

And here’s the deal: you’re going to want to go through each of those last two steps—testing and training your Agent, then scaling up—with each new template style. You don’t want an Agent with a High School Diploma in CMS Migration Expectations. You want an Agent with an Advanced Doctorate in My Site’s Migration Strategies.

I know that might feel annoying, but remember: we’re focused on the big picture of the migration here. An Agent isn’t a magic wand… it’s more like a DeLorean. You need to fuel the Flux Capacitor and get up to 88 MPH before the time-travel benefits can really be experienced.

Scale to Production

You’ve now trained your Agent. You’ve dealt with the minor inconveniences of training your Agent for the results you want.

This is where that effort compounds. Individual pages may take a while to complete, but because those pages execute concurrently, aggregate throughput is much higher.

That’s why that front-loaded training is so important. Once the agent is producing pages faster than your team can review them, you’ve created a new QA bottleneck.

This is another reason adding that QA Checklist as a skill in the beginning is such a smart move. Each page can now come with an automated QA readout so you or your QA team know where to pay particular attention.

The Humans Are the Loop

The Agent is doing the hard, annoying, tedious work. It will even review and assess its own work. But you will always want a human who really knows how your pages are supposed to look and perform to review, and possibly tweak, before your go-live.

The bottleneck isn’t gone, it’s just moved. No longer are you staring down the barrel of several months of migration work, daily stand-ups, and the limits of a human’s ability to stay focused on such tedious work.

Instead, your QA team may suddenly have more pages arriving for review than it was ever staffed to handle.

Ensure they have the staffing and support they need. They, like the Agent before them, need clear expectations. What does that 85% look like so they know if they need to send it back to the Agent or just pass it off to an Author to polish? Do they have enough people to get through all this in your window? Have you planned that timeline and staffed accordingly?

Bringing It All Together

So there it is. A Field Guide to Agentic CMS Migration… as of now. As I mentioned in the beginning, saying anything in the Agentic space is definitive is a fool’s errand because the space is constantly evolving. But the core truths are, I suspect, evergreen:

1. 01Plan Your Migration
2. 02Set Attainable, Clear Expectations
3. 03Train Your Agent
4. 04Start Small
5. 05Expand
6. 06Close It Out
7. 07Humans, Humans, Humans

Your Agent isn’t, yet, plug-and-play. Once calibrated, it isn’t quite Set It and Forget It. It is closer to Set the Standard, Watch the Exceptions, and Let the Agent Run.

The expectation of Agentic Migrations can cause us to see every human step as an annoyance, but the reality is that time spent up front in training can prevent countless hours of frustration down the road compared to a standard, human-led Migration.

Agentic migration does not remove humans from the process. It changes where their judgment has the most leverage. Humans define readiness, teach the system, resolve ambiguity, and make the final release decision. The agent applies that judgment at a scale no migration team could reasonably match by hand.

The up-front calibration is not overhead. It is what keeps the thousandth page from reproducing the first page’s mistakes at machine speed.