Documentation Center

Upgrade paths for the SDL Tridion 2013 SP1 HR1 Content Deployer Role

A reorganization of the Content Deployer feature means that you need to make some decisions about how to upgrade your existing Content Deployer setup.

The Content Deployer has, as of SDL Web 8.5, been reworked in three different roles:
Role nameRole folderDescriptionRuns as standalone microservice?Runs as Java/JSP Web application-based microservice?
Content Deployer endpointroles\deployer\deployerThe endpoint that receives published incoming contentyesyes
Content Deployer workerroles\deployer\deployer-workerThe processing engine that handles incoming content and stores ityesno
Content Deployer combinedroles\deployer\deployer-combinedThe previous two Roles combined in one.yesyes
As a result, as of SDL Web 8.5, you can upgrade Content Deployer to one of the following setups:
A Content Deployer endpoint and a Content Deployer worker, each running in a standalone microservice

This is a full migration to the new Content Deployer setup. The endpoint and processing part of your Content Deployer are separated, and the setup is fully scalable.

A single-role Content Deployer running in a standalone microservice

If you currently run your Content Deployer as a Windows service, Java process or .NET Web application, this is the least-effort upgrade of your Content Deployer. If you currently run your Content Deployer as a Java/JSP Web application, this migration to a standalone microservice is strongly recommended over an upgrade that would leave the microservice running inside a Web application. The drawback of this setup is that you cannot scale out, or separate the parts of, your Content Deployer.

A single-role Content Deployer running in a Java/JSP Web application-based microservice

If you currently run your Content Deployer as a Java/JSP Web application, this is the least-effort upgrade of your Content Deployer, but it is strongly discouraged. The drawbacks are that this upgrade is not provided with the product deliverable; that your Role runs as a deprecated Web application; and that you cannot scale out, or separate the parts of, your Content Deployer.

A Content Deployer endpoint running Java/JSP Web application-based microservice, and a Content Deployer worker running in a standalone microservice
If you currently run your Content Deployer as a Java/JSP Web application, this scenario is closer to a migration than to an upgrade. You enable the processing part of your Content Deployer (the worker) to be installed on a different machine, but your endpoint still runs in a Web application, which is a deprecated setup, and is strongly discouraged. The drawbacks are that this upgrade is not provided with the product deliverable, and that part of your Role still runs as a deprecated Web application.