A small serialisation change with a bigger meaning
Sitecore recently announced a change to how the PipelineArgs are serialised and deserialised in SitecoreAI. The Newtonsoft.Json configuration that currently uses TypeNameHandling.All will move to TypeNameHandling.None. For most implementations, this will probably go unnoticed, especially if you haven't deployed custom pipelines. Primitive values such as strings, numbers and booleans will continue to behave as expected. The main difference is that .NET type names are no longer serialised.The interesting part begins when custom code stores complex .NET objects in PipelineArgs.CustomData and later expects those objects to survive a serialisation and deserialisation round-trip. That pattern can depend on type information being written into the JSON itself. Once Sitecore removes that type metadata, the object may no longer come back as the same concrete .NET type.
At first glance, the natural reaction is to treat this as a compatibility problem. Find the affected code, adjust the serialisation logic, test the result and move on. Technically, that is a valid response. Architecturally, however, I think it misses the more important point.
If this change breaks custom in-process code in a SitecoreAI implementation, the first question should not necessarily be how to make that code work again. The first question should be why that code is there in the first place.
That distinction matters because SitecoreAI is not simply Sitecore XP hosted somewhere else. The platform moved to a different hosting model, where custom business logic should increasingly live outside the managed runtime and integrate through supported APIs, webhooks and services. A breaking serialisation change can therefore be more than an upgrade task. It can reveal an architectural dependency that should probably have been removed already.
How to test the new behaviour
Sitecore provides a feature flag that allows you to enable the new behaviour before it becomes the default. You do this through a normal Sitecore configuration patch:<sitecore>
<settings>
<setting name="PipelineArgs.DisableUnsafeSerialization">
<patch:attribute name="value">true</patch:attribute>
</setting>
</settings>
</sitecore>Deploy that configuration to a non-production environment and exercise the parts of the solution that contain custom pipeline logic, especially anything that stores complex objects in PipelineArgs.CustomData and expects those objects to be reconstructed after serialisation.
If nothing breaks, you are probably done.
If something does break, Sitecore's guidance is to update the affected customisation so it no longer relies on embedded type metadata, for example by using strongly typed models or explicitly reconstructing the expected object type after deserialisation.
That is the short-term compatibility path, and it is useful because it gives customers time to find issues before the new base image becomes the default.
For the full rollout guidance and configuration details, refer to Sitecore's original advisory and documentation.
My conclusion: stop deploying your own code to SitecoreAI
This is the part I think matters more than the serializer change itself. If enabling this flag exposes a custom pipeline dependency, I would not automatically treat that as a signal to modernise the pipeline code. I would treat it as a signal to remove the dependency.SitecoreAI is a managed SaaS platform. The further your implementation moves away from custom code running inside that platform, the better. Custom business logic should live in services you own and control, and SitecoreAI should be accessed through supported contracts such as APIs, webhooks and application extensions.
That separation is important for more than just this specific change. Every piece of code deployed into the Sitecore runtime increases your dependency on internal implementation details. Today it is TypeNameHandling. Tomorrow it might be another framework change, another runtime constraint or another security hardening measure. If your customisation reacts to an event, use a webhook. If it needs to read or modify content, use the SitecoreAI APIs. If it performs business logic, move that logic into an external service. If it provides a larger extension, build it as an application instead of embedding it in the platform runtime.
Of course, there will be older implementations where that migration cannot happen immediately. In those cases, fixing the serialisation logic may be a perfectly reasonable temporary measure. But it should remain temporary. Please advice the team to log this kind of technical debt, put in on your backlog. Do not invest more than necessary in keeping legacy in-process customisations alive.
Use the feature flag to find them. Put them on the board. Fix them if you need time. Then remove them.