Sitecore Scheduled Publish (for XM/XP) 10.5: Shipping Without Package Designer (Items as Resources, NuGet, Docker)

If you have been following my Sitecore Scheduled Publish module, you know it has been around for a while. The module lets content editors schedule a publish or unpublish of an item for a future date and time, with notifications. It was originally built by Hedgehog Development (Apache-2.0), and I maintain the actively developed version, with releases for Sitecore 10.2, 10.3, 10.4, 10.4.1, and now 10.5.

This post is about the 10.5 release — not just because it adds Sitecore 10.5 support, but because it required a completely different approach to packaging and distribution.

The Problem: No More Package Designer

Sitecore 10.5 disables Package Designer by default, and Sitecore recommends keeping it disabled. If you are a module author, this is a big deal. Sitecore modules have traditionally been built in Package Designer and installed with the Installation Wizard. That entire workflow is gone now.

So the question becomes: how do you ship a Sitecore module when the tool everyone used to build and install packages no longer exists?

The Answer: Items as Resources (IAR)

For this release, I moved entirely to Items as Resources (IAR). Instead of a Sitecore package that writes items into the database during installation, all module items now ship as .dat resource files. Installing the module means copying 6 files into your webroot. No package, no Installation Wizard, no database writes.

The module ships 57 items in master and 11 in core — templates, settings, the scheduled task definition, and the core ribbon, gutter, and field type registrations. These are the files:

bin/ScheduledPublish.dll
App_Config/Include/ZZ_ScheduledPublish/ZZ_ScheduledPublishControl.config
App_Data/items/master/items.master.schedule.publish.dat
App_Data/items/core/items.core.schedule.publish.dat
sitecore/shell/Applications/Content Manager/Dialogs/Schedule Publish/Schedule Publish.xml
sitecore/shell/Applications/Content Manager/Dialogs/Edit Scheduled Publish/Edit Scheduled Publish.xml

How to Install — Four Options

I wanted to make sure teams can install this however works best for their setup. Pick one of the following.

Option 1: NuGet (Recommended for CI/CD Pipelines)

Add the package to your Sitecore web project:

dotnet add package SCScheduledPublish

To stay on Sitecore 10.5 and pick up module updates automatically, use Version="10.5.0.*" in your PackageReference.

The DLL is referenced as usual. The config, IAR, and dialog files are automatically added to the web project's publish output at the correct paths. Deploy the way you normally do — Web Deploy, PaaS pipeline, or Docker build. The package is on nuget.org.

Option 2: File-Drop Zip

Download the IAR zip from the latest GitHub release and extract it into your CM (and CD) webroot. On Azure PaaS, use Kudu or the zip deploy API. In a Docker image:

COPY ./scheduled-publish/ C:/inetpub/wwwroot/

Recycle the app pool (or restart the container) afterwards.

Option 3: Docker Module Asset Image

Pre-built module asset images are available on Docker Hub. The images follow the standard Sitecore module asset image layout (\module\cm\content). Use the tag that matches your CM image's Windows base: 10.5-ltsc2025 for Windows Server 2025, 10.5-ltsc2022 for 2022.

Copy the module files into your CM image using a multi-stage Dockerfile:

ARG BASE_IMAGE
ARG SCHEDULED_PUBLISH_IMAGE=nehemiah/sitecore-scheduled-publish:10.5-ltsc2022

FROM ${SCHEDULED_PUBLISH_IMAGE} AS scheduledpublish

FROM ${BASE_IMAGE}
...
COPY --from=scheduledpublish \module\cm\content .\

Option 4: From Source

Clone the Sitecore Scheduled Publish repo on GitHub and add the project to your solution. Deploy the files, then either push items to the database with the Sitecore CLI:

dotnet sitecore ser push -i ScheduledPublish

Or generate the IAR files yourself:

dotnet sitecore itemres create -i ScheduledPublish -o <webroot>/App_Data/items/schedule.publish

Then move each items.<db>.schedule.publish.dat into App_Data/items/<db>/.

Verify the Install

After installing through any of these methods, you can verify it worked:

• The Content Editor Publish ribbon shows the Scheduled Publish strip.
• /sitecore/system/Tasks/Schedules/ScheduledPublishTask and /sitecore/system/Modules/Scheduled Publish exist.
• /sitecore/admin/showconfig.aspx contains the ZZ_ScheduledPublish settings.

Versioning

Starting with 10.5, versions follow <Sitecore version>.<module revision>. So 10.5.0 was the first release for Sitecore 10.5, and 10.5.0.1, 10.5.0.2, etc. are module updates that do not require a new Sitecore version. This leaves 10.5.1 free for a future Sitecore 10.5.1 release. NuGet sorts these correctly.

On Docker Hub, the 10.5-<base> floating tags always point to the newest build for Sitecore 10.5, while exact tags like 10.5.0.1-ltsc2025 never change.

Available Docker Images

Here is the full list of Sitecore Scheduled Publish Docker images:

Tag	Sitecore Version	Windows Base
10.5-ltsc2025	10.5	Windows Server 2025
10.5-ltsc2022	10.5	Windows Server 2022
10.5.0.1-ltsc2025	10.5	Windows Server 2025
10.5.0.1-ltsc2022	10.5	Windows Server 2022
latest	10.5	same as 10.5-ltsc2022
10.4.1-ltsc2022	10.4.1	Windows Server 2022
10.4.1-1809	10.4.1	Windows Server 2019
10.4-ltsc2022	10.4	Windows Server 2022
10.4-1809	10.4	Windows Server 2019
10.3-1809	10.3	Windows Server 2019
10.2-1809	10.2	Windows Server 2019

Sitecore 10.5 adds support for Windows Server 2025 containers and drops 1809 / ltsc2019, so the 10.5 images follow the same pattern. The 10.5 images include OCI labels for version, source commit, build date, and license.

While working on the Docker images, I found that the existing 10.4.1-1809 tag actually contained a Windows Server 2022 image — which would fail on Windows Server 2019 hosts. I rebuilt it on a proper 1809 base and verified the files byte-for-byte.

IAR Upgrade Guidance: What to Clean Up and What to Keep

This is the part I think the community will find most useful, because the IAR upgrade behavior is not obvious.

The key thing to understand: database copies take precedence over IAR files. If an item from an IAR .dat file also exists in the database (because it was installed via the Installation Wizard or ser push in a previous version), the database copy wins. That means module updates shipped through IAR will stay hidden for those items.

So the question is: when do you need to clean up those database copies?

Situation	Cleanup Needed?
Fresh install	No. Nothing is in the database.
Upgrade from Installation Wizard or ser push install	Yes. All module items are in the database and override the new IAR items.
Upgrade from a 10.4 / 10.4.1 IAR install	Usually no. Only items written at runtime are in the database.

But you need to be careful about what you clean up. There are items you should keep in the database:

• ScheduledPublishTask — Sitecore copies this to the database on every run to save the "Last run" timestamp. You will see migrated to head provider in the logs. This is expected.
• Customized settings — If an admin has changed the module's settings under /sitecore/system/Modules/Scheduled Publish, a forced cleanup would reset them.
• Editors' schedules — Active publish schedules created by content editors under the Publish Schedules folder. These are normal database items, not part of the IAR files.

The safe approach is to use dotnet sitecore itemres cleanup in stages. Log in to the CM with dotnet sitecore login first.

Step 1 — Preview what would be removed:

dotnet sitecore itemres cleanup --what-if

Step 2 — Remove copies that are identical to the IAR version. Customized items are skipped automatically:

dotnet sitecore itemres cleanup

Step 3 — Force-remove only the module definitions that nobody edits by hand, so the new template and ribbon versions take effect:

dotnet sitecore itemres cleanup -p "/sitecore/templates/Scheduled Publish" -r --force

The documentation lists all the core-database definition paths for Step 3.

Never use --force on /sitecore/system/Modules/Scheduled Publish. It would reset your email and section settings to the defaults.

Tested on Real Sitecore 10.5

IIS (XM, Sitecore Kernel 20.0.158): The zip installed cleanly. All 57 master and 11 core items loaded from IAR with 0 errors. I ran through the full scheduled publish cycle — create a schedule, wait for the ScheduledPublishTask to fire, confirm the item publishes to web, verify the schedule updates. One thing to know: the scheduled publish runs on the first Master_Database_Agent check after the scheduled time. That check runs every 10 minutes by default, so a publish can run up to about 10 minutes after the scheduled time. On IIS it ran about 9 minutes after. The interval is configurable — see Job Interval Configuration in the docs.

Docker (XM1, ltsc2025): Built the CM image from the published Docker Hub image layered onto scr.sitecore.com/sxp/sitecore-xm1-cm:10.5-ltsc2025. All containers came up healthy, all 68 IAR items loaded, 0 errors. The full scheduled publish cycle passed here too — schedule created, ScheduledPublishTask fired about 2 minutes later, published the item to web, schedule updated. Run took about 1.4 seconds.

Why This Matters

It is an example of how a community module can ship for Sitecore 10.5 without Package Designer. The approach — IAR files, NuGet with build targets, Docker asset images, and CI with Trusted Publishing — can serve as a reference for other module authors who need to move away from the Installation Wizard.

The module is also ready for Windows Server 2025 containers from day one, which is new in Sitecore 10.5.

Build and Release Automation (For Module Authors)

For anyone maintaining a Sitecore module, the build and release pipeline might be useful as a reference. The entire process is automated with GitHub Actions.

When I push a Sitecore_<version> tag, the workflow generates IAR files from serialized items using Sitecore CLI, builds the DLL, produces the file-drop zip, packs the NuGet package, publishes to nuget.org using NuGet Trusted Publishing (OIDC — no API key stored anywhere), and creates a GitHub release with all artifacts attached.

You can also build locally with PowerShell:

pwsh ./scripts/Build-Package.ps1 -Version 10.5.0.1

To also build the Docker images (the script lists every Docker tag to push, including the exact 10.5.0.1-* tags):

pwsh ./scripts/Build-Package.ps1 -Version 10.5.0.1 -DockerRepository nehemiah/sitecore-scheduled-publish
docker push nehemiah/sitecore-scheduled-publish:10.5-ltsc2025
docker push nehemiah/sitecore-scheduled-publish:10.5.0.1-ltsc2025
docker push nehemiah/sitecore-scheduled-publish:10.5-ltsc2022
docker push nehemiah/sitecore-scheduled-publish:10.5.0.1-ltsc2022

Getting the CI pipeline right took a few iterations — I had to add a repo-level NuGet.config with the Sitecore feed, fix .nupkg path resolution for Windows runners, and make the release step rerunnable. All fixes are in the repo as separate PRs (#24, #25, #26).

Links

• Documentation
• Latest GitHub release
• SCScheduledPublish NuGet package
• Sitecore Scheduled Publish Docker images
• Sitecore 10.5 Install and Upgrade guide
• Main PR (#23)

If you are maintaining a Sitecore module and need to figure out the post-Package Designer distribution story, take a look at the repo. The build script, GitHub Actions workflow, NuGet targets, and Docker setup are all there. If you find it useful, a star on GitHub helps with visibility.

What Is New in SitecoreAI Pathway

Back in April 2026, I spent a few weeks exploring SitecoreAI Pathway and presented my findings at the Sitecore User Group Coimbatore (SUGCBE). I wrote three posts about it - a high-level comparison with the old migration tool, a step-by-step walkthrough of the Sitecore Website path, and a walkthrough of the Any Website path.

In those posts, I called out the beta limitations - 50 URL cap, single language per run, no image handling for crawled sites, no way to guide the AI's decisions.

I recently went through the latest official documentation and several of those limitations are gone. Here is what I found.

The 50 URL Limit Is Now 200

When I crawled my blog with the Any Website path, Pathway picked up 50 pages from the sitemap and stopped. My blog has more than 50 posts, so I was leaving content behind.

The docs now say the crawler supports up to 200 URLs. For a blog like mine, 200 covers everything. For larger enterprise sites you would still need multiple runs, but it is a much more practical starting point.

Multi-Language Support

In my earlier testing, Pathway supported only a single language per migration run. If your site had content in English, French, and German, you needed three separate runs.

The docs now say "SitecoreAI Pathway supports sites in multiple languages." I have not tested this hands-on yet, so I cannot say how language detection and mapping work in practice. But the single-language constraint was one of the first things people asked me about after my SUGCBE talk, so it is good to see it addressed.

Image Import for the Any Website Path

When I used the Any Website path to crawl nehemiahj.com, Pathway migrated the page content but not the images. For the Sitecore Website path, you could use the old XM to XM Cloud Migration Tool to move media separately. But for the Any Website path, there was no image solution at all.

The docs now say: "If enabled, the SitecoreAI Pathway app also imports images from the scraped website." And for non-Sitecore sites, "media is scraped from the source site and moved to /sitecore/media library/project."

So the Any Website path can now handle both content and images in a single run. The "if enabled" part suggests there is a toggle for this - I want to find it and see how the imported images look in the media library.

Specific URL List Instead of Just Sitemap

During my April testing, the crawler relied entirely on the sitemap.xml to discover pages. If your sitemap was incomplete or missing, the crawler would miss content.

The docs now say you can provide "the sitemap.xml file of the source site or the URLs to specific website pages." So you can give Pathway a curated list of URLs instead of depending on the sitemap. Useful when you want to migrate specific sections of a site, or when your sitemap does not include everything.

.NET 10.0 for the Sitecore Website Path

A smaller change, but if you are following the Sitecore Website migration path - the XMComponentExtraction console app now requires .NET 10.0 instead of the .NET 9.0 I used during my testing. Make sure you have the updated runtime before setting up the extraction toolchain.

What Has NOT Changed

A few things remain the same based on what I can see in the docs:

• Two migration paths - Sitecore Website and Any Website are still the two options. The core workflow (extract → audit → map → migrate) has not changed.
• Target structure required first - You still need to set up your SitecoreAI site structure (templates, components, page designs, partial designs) before running Pathway. It maps to existing structures, it does not create new ones.
• Media library migration for Sitecore path - The old XM to XM Cloud Migration Tool is still needed for migrating media from Sitecore XM/XP sources.
• No page/partial design migration - The docs still say Pathway does not migrate page and partial designs, or XP-related items like xDB data, personalization, and email marketing content.

What I Want to Test Next

Reading the docs is one thing. Actually running a migration with these changes is another. Here is what I plan to test in my next hands-on session:

• The 200 URL limit - Can Pathway now crawl all my posts in a single run?
• Image import - Does the toggle actually pull blog images into the media library? How does the quality and organization look?
• URL list input - Can I feed Pathway a specific list of pages instead of the sitemap? How does the UI handle this?
• Multi-language - I will need a multilingual test site for this, but it is high on my list.
• Overall migration quality - Has the AI mapping improved? I am curious if the tool has become more reliable.

I will share the results with screenshots in my next post.

Still on My Wish List

A few things I hoped would change but have not, at least based on the docs:

• AI customization - Still no way to guide the AI's mapping decisions. You cannot tell it "these are product pages, not blog posts" before it runs.
• Re-run capability - If something fails mid-migration, you may still need to start over.
• JavaScript-rendered content - The crawler still works with static HTML. Single-page apps built with React, Angular, or Vue will not be fully captured.

That said, the changes so far address the things that made Pathway hard to use in practice. The 50 URL limit was the biggest one - it made the tool feel like a demo rather than something you could use on a real project. At 200 URLs with image import, the Any Website path is now a lot more practical.

If you tried Pathway earlier and ran into the same constraints I did, it is worth another look.

SitecoreAI Pathway — Migrating from a Sitecore Website (Step-by-Step Walkthrough)

In my previous post, I compared SitecoreAI Pathway with the old XM to XM Cloud Migration Tool at a high level. In this post, I am going deeper — walking through the Sitecore Website migration path step by step, with screenshots from my actual testing.

This is the path most Sitecore developers and administrators will follow when migrating from an existing Sitecore XM or XP instance to SitecoreAI (XM Cloud). It involves extracting source data using the XMComponentExtraction tool, exporting your target site structure, and letting Pathway's AI handle the content audit, mapping, and migration.

I am sharing this as someone still exploring the tool — these are my hands-on findings, not expert advice. If you spot something I have missed or interpreted differently, I would love to hear from you.

Prerequisites Before You Begin

Before starting the migration in Pathway, make sure these are in place:

• Target SitecoreAI site structure — Your target environment should already have templates, renderings, component templates, and page designs configured. Pathway maps content to existing structures; it does not create new ones.
• Media assets migrated — All in-scope media should be moved from source to target first. You can use the XM to XM Cloud Migration Tool for this, as Pathway does not handle media library migration for the Sitecore website path.
• .NET 9.0 Runtime — Required on the machine where you will run the XMComponentExtraction console app.
• PowerShell 7+ — Required for running the export-structure.ps1 script.
• CM access — You need access to the source Sitecore CM instance for deploying the extraction handler and running the tool.

Step 1 — Select CMS (Sitecore Website)

After installing Pathway from the Sitecore Cloud Portal Marketplace, click on it from the Apps section on your Home page. You will land on the migration creation screen.

Select "Sitecore website" as your source. The description says "Extract content from a Sitecore XM website." Give your migration a name and description, then click Next.

Step 1 — Selecting "Sitecore website" as the source and entering migration details

Notice there is also an "Any website" option here — that is the web crawling path I will cover in the next blog post.

Step 2 — Configure SitecoreAI Instance

Step 2 is the most involved part of the setup. There are three things happening on this screen:

1. Configure target environment — On the left, select your target SitecoreAI environment and site. The site path auto-populates based on your selection and gets locked after you initialize the migration.

2. Upload target SitecoreAI structure — In the middle section, upload your xmc-structure.json file. This tells Pathway what templates, renderings, and page designs exist in your target environment so it knows what to map to.

3. Generate storage for source data — Below that, Pathway generates an Azure Blob Storage URL. This is where your extracted source data will be uploaded. Copy this URL — you will need it when running the XMComponentExtraction tool.

Step 2 — Configuration screen with target environment, structure upload, and Azure Blob Storage URL

Click "Migration Initialized" to start. You will see a confirmation message "Migration initialized successfully." The Migration Summary panel on the right shows all the details.

When you click "Read instruction here" next to the SitecoreAI Structure section, a popup appears with instructions to download the CMSExportStructure package.

Download CMSExportStructure package — this generates the xmc-structure.json file

Preparing the Target Structure (xmc-structure.json)

This is a step that happens outside of Pathway. You need to generate the xmc-structure.json file that describes your target site's structure.

The approach I followed:

1. Create a Sitecore package from the target SitecoreAI environment containing the relevant items — Components, Pages, Renderings, and Presentation.
2. Download and extract the package zip file.
3. In the extracted folders, you will see GUID-named subfolders — this is the standard Sitecore serialization format. Each folder represents an item.
4. Place these in the corresponding folders expected by the export script.
5. Run the PowerShell script: pwsh -NoProfile -ExecutionPolicy Bypass -File .\export-structure.ps1

Extracted folder structure — Components, Pages, Presentation, Renderings with GUID-named item folders

The script reads these serialized items and outputs the xmc-structure.json file. Here is what the JSON structure looks like:

xmc-structure.json — contains Pages, Renderings, and PageDesignMappings from the target site

The JSON contains four main sections: Pages (page templates with their IDs and fields), Renderings (components like "Related Blog Articles" and "Reviews" with their template types), PageDesignMappings (linking page templates to page designs), and PageDesigns.

Alternatively, if you are using Sitecore Content Serialization (SCS), you can serialize items directly instead of creating a Sitecore package.

Once the JSON is ready, upload it back in the Pathway configuration screen. You will see a confirmation: "SitecoreAI structure file uploaded successfully."

Structure uploaded successfully — note the confirmation message and the Migration Summary showing "Uploaded" status

Extracting Source Data — XMComponentExtraction

Now for the source side. The XMComponentExtraction tool extracts page data as JSON from your Sitecore XM/XP instance. It supports On-Prem, PaaS, and Container environments.

The tool has two parts:

• ExtractorHandler.ashx — A handler that exposes endpoints using the Sitecore Item API on the CM server.
• Extractor.App.Con.exe — A .NET 9.0 console application that calls the handler and uploads extracted data to Azure Blob Storage.

Important prerequisite: Before running the extraction, update the Sitecore.Services.SecurityPolicy setting in .\App_Config\Sitecore\Services.Client\Sitecore.Services.Client.config to ServicesOnPolicy. This grants access to Entity and Item Services that the handler needs. Remember to revert to ServicesLocalOnlyPolicy after extraction is complete — this is a security consideration.

To install the handler, copy ExtractorHandler.ashx to your CM's wwwroot/sitecore/admin directory. Verify it works by navigating to: /sitecore/admin/ExtractorHandler.ashx?action=getallsitenames

Then run the console app with the required parameters:

.\Extractor.App.Con.exe --cmHostName=sc1041cm.dev.local --userName=admin --password=b --uploadUrl="<Azure Blob SAS URL from Pathway>"

The tool prompts you to select the site name and enter the language code. Then it processes the items and uploads them to Azure Blob Storage.

XMComponentExtraction console output — login, site selection (website), language (en), processing, and "Extractor App Ended"

Once this completes, the source page data is in Azure Blob Storage. From this point, Pathway handles everything within the SitecoreAI environment — you do not need to keep your source system connection active.

Step 3 — Content Audit

Back in Pathway, Step 3 is where the AI takes over. There are two actions here: Grouping and Template Mapping.

Grouping — Click the Grouping button and the AI analyzes all extracted pages, grouping them by source template. In my test with a simple demo site, it found 1 group ("Sitecore Experience Hub") with 1 page (Home). For real-world sites with hundreds of pages, this is the step where Pathway's value becomes clear — instead of mapping every page individually, the AI identifies common patterns and groups similar pages together.

Template Mapping — Next, click Template Mapping. The AI matches each group to the most appropriate target template. You can click "View template match details" to see the AI's reasoning — why it chose a particular mapping based on page structure and content. In my case, the "Sitecore Experience Hub" group was mapped to the "Page" target template.

Content Audit — Grouping completed (1 group, 1 page), Template Mapping completed, showing "Sitecore Experience Hub" group

Step 4 — Map Content

In Step 4, the AI maps source components to target SitecoreAI components. You can review the suggested mappings and adjust them manually if needed.

Clicking "View page details" shows you the specifics — the page path, page ID, template name, and template ID. This helps you verify that the mapping makes sense for your content model.

Map Content — Component Mapping completed, with Page details showing the Home page mapped to "Page" template

Step 5 — Migration

The final step — click the Migration button and watch the real-time dashboard.

Here is where I have to be honest about my experience. In my test with a simple demo site (1 page), the migration result was 0 succeeded, 1 failed. The Home page at /sitecore/content/Home failed to migrate.

Migration result — 0 succeeded, 1 failed. The Home page did not migrate successfully.

I want to be transparent about this because it reflects the reality of working with a tool that is still in beta. The failure could be due to several factors — how the demo site was set up, a mismatch in the component mapping, or a limitation in the current version. This is a simple test site and not a complex real-world scenario, so the failure might be specific to my setup.

In contrast, my "Any Website" migration (using the web crawling path with my blog nehemiahj.com) migrated all 50 pages successfully — 50 succeeded, 0 failed. I will cover that walkthrough in my next post.

What I Learned

A few takeaways from this walkthrough:

The prerequisite setup takes time. Between deploying the XMComponentExtraction handler, changing SecurityPolicy settings, preparing the target structure JSON, and managing the Azure Blob URL, there are several moving parts. Plan for this upfront rather than expecting it to be quick.

The CMSExportStructure step needs attention. Getting the right items serialized and placed in the correct folder structure for the PowerShell script is important. If your JSON is incomplete or missing renderings, the AI will not have enough information to map correctly.

AI reasoning is available but not customizable. You can see why the AI made certain mapping decisions through the "View template match details" option. But you cannot guide or instruct the AI — for example, telling it "these are product pages, not blog posts." This is something I hope Sitecore adds in a future update.

Failures happen and that is okay. The tool is in beta. Not every migration will succeed on the first run, and understanding why it failed is part of the learning process. Post-migration review and refinement should be expected.

The Security Policy change is easy to forget. Reverting ServicesOnPolicy back to ServicesLocalOnlyPolicy after extraction is a security step that should not be skipped. Consider adding it to your migration checklist.

Up Next

In the next post, I will walk through the "Any Website" migration path — using Pathway's built-in web crawler to migrate content from my blog (nehemiahj.com). That test had a much better outcome (50/50 success), and the web crawling approach is simpler to set up since it does not require XMComponentExtraction or Azure Blob Storage.

Useful Links:

• Part 1 - SitecoreAI Pathway vs XM to XM Cloud Migration Tool
• SitecoreAI Pathway - Official Page
• Sitecore Docs - Migrate from a Sitecore XM Website
• My XM to XM Cloud Migration Tool series