Partial content migration from Kentico 12 to Xperience by Kentico

Hi all,

We're planning a **content-only migration from Kentico 12 to Xperience by **

Kentico and have a somewhat unique requirement: we don't need a full

migration. We only need to bring over a specific subset of content types, and

only items created or modified from a certain date onward (not the full

history).

Our target XbyK environment already has an existing solution in place with its

own content, so we need to be careful not to overwrite or delete anything

that's already there.

I have a few questions I'm hoping the community can help with:

1. Has anyone done a partial / scoped migration like this before?

Specifically — migrating only a defined list of content types from K12 to

XbyK, filtered by date, rather than doing a full migration. I'd love to hear

about your experience and any lessons learned.

2. What's the best approach to narrow the migration scope?

We want to include only a specific set of content types and only items from a

given date forward. Is this best handled through:

- Configuration/filtering options in the Kentico Migration Toolkit?

- Custom SQL queries or data extraction on the K12 side before running the

migration?

- Some other approach?

What has worked well (or not) for limiting scope?

3. Are there any gotchas or things to watch out for?

Thinking about things like:

- Orphaned references or broken relationships when you only migrate a subset

- Dependencies between content types that might not be obvious

- Media/attachment handling when the related page types aren't included

- Tree structure / page hierarchy considerations

- Anything else that bit you during a partial migration

**4. How to integrate migrated items into an existing XbyK solution via **

Continuous Delivery without overwriting existing content?

Once the migration is complete in a staging XbyK instance, we need to bring

those items into our existing production solution. Our current workflow uses

Continuous Delivery (CD) for deployments. What's the safest way to:

- Export only the newly migrated items from the staging instance

- Import them into the existing solution via CD

- Ensure nothing already present gets overwritten or deleted in the process

Is CD's restore mode the right fit here, or is there a better pattern for

merging net-new content into an existing environment?

---

Environment:

- Source: Kentico 12

- Target: Xperience by Kentico (31.3.0)

- Migration scope: Content only (no custom code, templates, or site settings)

- Deployment: Continuous Delivery

Thanks in advance for any guidance or shared experience!

Tags:
CI/CD Migration / upgrade

Answers

Accepted answer

Hey Mike! I may be able to help, as this is exactly what i've been doing for my own site (12 to Xperience, rebuilding and restructuring during imports). A lot of this can be done with the migration toolkit, but I myself did things manually because I was also restructuring a lot and needed to 'clean up' the old content manually during the processes (which sometimes is easier in an excel + markdown)

  1. Yes, while I don't "filter by date" I am doing a restructure, so i have a ton of scripts that I can share with you that migrate my content, including reading from CSV files, getting old page metadata, moving images/attachments into the content hub, etc.
  2. I can only speak largely on custom migration (which includes querying the old database tables, if you have the old connection string you can use the new DataConnection{ CustomQueryText = "MyQuery", ConnectionString = "The Old Connection String"}.GetDataContainerAsync()). The Migration toolkit IS powerful, i've seen some of the hooks, and it can do a LOT of stuff for you. So look there first probably, but otherwise I can get you some sample scripts from my repo.
  3. My scripts have parent-child relationships available, but again I was reforming static content into structure, so i was creating new structured content from old, not reorganizing structured content. The Migration Toolkit has hooks to handle child references and such. What I also did with my migration (i don't think this is 'native' to the migration toolkit) is on many of the things I imported, i added a "OldUrl" field, which i placed old urls, then I was able to build a comprehensive Migration table with the old URLs to the new Url, and hooked that logic up. I plan on eventually (once everything is migrated) run a variation of my Media to Blob Storage migration scripts that scan for old urls and replace them with the new. The Migration Toolkit I THINK keeps the MediaGuid and Attachment Guid as the ContentItemGuid, but that is one thing to watch out for. I prefer it, but it's tricky, i had to do some fancy finagling to upload, then update the ContentItemGuid and move the file in Azure Blob Storage, again i have scripts if needed.
  4. Again i'm not an expert on CI/CD (it's my own site and business, so i'm a baddy and import directly into the production site _'). I would probably take a time to copy down all the important data into your dev environment, run the import, and then push back up. Having a window to prevent users from modifying would be good. You can use Sync if you wish since it all should be Content Items, and that may give you more granule level than CI/CD though, so look into that instead first.

Hit me up if you want to do a call - `$"\{firstInitial\}\{lastName\}@gmail.com"

To response this discussion, you have to login first.