Legacy IDs into Sitecore AI: from on-prem Item Service to SCS YAML

 We didn’t set out to invent a migration framework. We needed physician-related templates (and a bit of lookup content) on Sitecore AI DEV — with the same item IDs as the legacy XM database — so anything that already keyed off those GUIDs wouldn’t fall apart later.

Packages felt like the quick button (but that is gone :( ). YAML ended up being the better long-term play. This is how that played out, including the boring parts that actually burn the day.

The real problem

My main task was to pull some templates from legacy system and move to the new SitecoreAI env, in short, find all templates related to physician template and move all that to SitecoreAI, that was not so fun task if you do it the old way, but to have some fun, lets use AI :) 

XM/XP to SitecoreAI

We only cared about the physician slice first: PhysicianTemplate, related bases, lookup templates behind Treelist/Droplist sources, then sample content so editors could actually pick Facilities, Specialties, etc.

End to End Pipeline

Thinking about solution

We wanted to use Sitecore CLI with legacy XM instance but I didn't have a fully setup local instance, I don't have identity installed which is requested for setting up CLI, I didn't want to go through the configuration and setup of all that so what would be the alternative?! 

 Sitecore Services Client (SSC) Item Service was enough.

Session auth worked; raw Basic auth later returned 403:

Don't worry about the above, you don't have to do it yourslef, all what you need to have is Cursor or any other AI tool, just provide the URL to sitecore, username and password, then ask it to authenticat and use the item service! 

Once you have the agent tool connected to legacy system, you can ask it to do query anything in your legacy DB, and once you know that you need you can generate yml files, again, you don't have to do anything, you just need to have scs setup on your current solution code, ask agent to create a separate module for migrated template/content. 

Constraints that mattered:

• Keep legacy IDs (I want to maintain the Ids use on old --> for content migration goal). 
• Don’t boil the ocean (not every Feature template, not 19k office addresses)
• Land something dotnet sitecore ser push can own going forward

Package vs YAML

We talked about SPE + package as a bridge. Fine for a one-shot. Bad if you want reviewable diffs, partial updates, and a module you can push again next week. So we went Sitecore Content Serialization YAML, under a dedicated module, paths matching legacy, IDs copied from the source items. That choice paid off the first time ser validate yelled about file layout. Fixing folders in git is nicer than re-exporting a .zip.

How we actually pulled data

Identity wasn’t in the picture on that local CM. Sitecore Services Client Item Service with a normal login session worked; plain basic auth got us 403s later, which was a fun rediscovery.

Examples of getting item query: 

A few practical notes:

• Children-by-path was flaky; children-by-ID was reliable.
• fields=* sometimes gave us empty shells. Asking for standard fields without the star, or naming fields explicitly, behaved better.
• Once we had an item graph, we dumped JSON, then generated YAML with ID / Parent / Path taken straight from the source.
• Nothing fancy — just enough API glue to walk a template and its sections/fields/__Standard Values.

Hoping this is helpful and open a door toward easily dealing with legacy content.