Decommissioning of AEM Servers | Community
Skip to main content
Level 4
August 26, 2025
Solved

Decommissioning of AEM Servers

  • August 26, 2025
  • 2 replies
  • 923 views

Hi,

 

We are analysing on decommissioning the Production servers but also wanted to check here for any pointers/tips to consider if we want to reduce the number of AEM Publisher and dispatcher servers in Production if someone has already worked on this before?

For ex: Out of 4 Publishers and 4 dispatchers, if we would want to reduce to 2 each as most of the sites are migrated to a different tool and we are just left with 8 out of 21 sites.

Thank you 

 

Best answer by SantoshSai

Hi @shibani06,

If you are planning to reduce the number of Publishers and Dispatchers in Production, there are a few important points to consider before scaling down:

  1. Traffic & Load Analysis

    • Check your traffic patterns (page views, concurrent users, API calls) for the remaining 8 sites.

    • Run load tests on 2 publishers + 2 dispatchers to confirm they can handle peak loads comfortably.

  2. Redundancy & HA

    • Moving from 4 → 2 publishers/dispatchers reduces fault tolerance. If one node goes down, you’ll only have 1 left.

    • Ensure your load balancer health checks and failover strategy are solid.

  3. Content Publishing & Replication

    • Reconfigure Author replication agents to point to the new publisher list.

    • Check replication queue throughput during bulk publishes—2 publishers need to handle all traffic flushes now.

  4. Dispatcher Configuration

    • Update your load balancer config when reducing dispatchers.

    • Validate cache hit ratio and invalidation rules to avoid bottlenecks.

    • Warm up cache after scale-down to reduce first-hit latency.

  5. Monitoring & Alerts

    • Put strong monitoring in place for CPU, memory, GC, replication queues, and dispatcher cache health.

    • This is critical because fewer nodes mean less buffer if something spikes.

  6. Disaster Recovery / Rollback Plan

    • Keep automation (CloudFormation, Ansible, etc.) ready so you can quickly scale back to 4 if needed.

    • Test the rollback before cutting servers.

  7. License & Cost

    • Verify with Adobe if your license terms are per-core/instance and whether reducing infra affects compliance.

In short: Yes, you can scale down to 2 publishers + 2 dispatchers if your remaining 8 sites have much lower load. Just make sure you validate with load testing, have strong monitoring, and keep a fallback plan.

2 replies

SantoshSai
Community Advisor
SantoshSaiCommunity AdvisorAccepted solution
Community Advisor
August 26, 2025

Hi @shibani06,

If you are planning to reduce the number of Publishers and Dispatchers in Production, there are a few important points to consider before scaling down:

  1. Traffic & Load Analysis

    • Check your traffic patterns (page views, concurrent users, API calls) for the remaining 8 sites.

    • Run load tests on 2 publishers + 2 dispatchers to confirm they can handle peak loads comfortably.

  2. Redundancy & HA

    • Moving from 4 → 2 publishers/dispatchers reduces fault tolerance. If one node goes down, you’ll only have 1 left.

    • Ensure your load balancer health checks and failover strategy are solid.

  3. Content Publishing & Replication

    • Reconfigure Author replication agents to point to the new publisher list.

    • Check replication queue throughput during bulk publishes—2 publishers need to handle all traffic flushes now.

  4. Dispatcher Configuration

    • Update your load balancer config when reducing dispatchers.

    • Validate cache hit ratio and invalidation rules to avoid bottlenecks.

    • Warm up cache after scale-down to reduce first-hit latency.

  5. Monitoring & Alerts

    • Put strong monitoring in place for CPU, memory, GC, replication queues, and dispatcher cache health.

    • This is critical because fewer nodes mean less buffer if something spikes.

  6. Disaster Recovery / Rollback Plan

    • Keep automation (CloudFormation, Ansible, etc.) ready so you can quickly scale back to 4 if needed.

    • Test the rollback before cutting servers.

  7. License & Cost

    • Verify with Adobe if your license terms are per-core/instance and whether reducing infra affects compliance.

In short: Yes, you can scale down to 2 publishers + 2 dispatchers if your remaining 8 sites have much lower load. Just make sure you validate with load testing, have strong monitoring, and keep a fallback plan.

Santosh Sai
SHIBANI06Author
Level 4
August 28, 2025

Thank you Santhosh

ksuren
Level 3
August 28, 2025

You'll should be okay as long as the website traffic load on the servers are not high, that is if the website usage is not high. Again this is a general question and also need to see what content is being served, regions, languages, APIs/integrations etc. need to be accounted for.

 

We did something similar for a static content website - but had high visits (sometimes).

  • Run load tests on the lower env, that mimics Prod and see how the servers are performing.
  • Then to reduce 1 set (1 Publish, 1 Dispatcher) to get the consensus on the load and response times. And decided accordingly.
    • 1 Author (shared across both blue and green environments)

    • 3 Publish instances - 2 active (blue live); 1 configured as a standby (green)

    • 3 Dispatcher instances - 2 active (blue - serving live traffic) and 1 standby (green - to take over during cutover or failover)

Ref: https://experienceleague.adobe.com/en/docs/experience-manager-cloud-manager/content/introduction#blue-green following the same idea but for our on-premise.

SHIBANI06Author
Level 4
August 29, 2025

Thank you but the AEM version being used is AEM 6.4

ksuren
Level 3
August 29, 2025

Technically, 6.4 should be similar.

 

On the version, you should consider upgrading - https://helpx.adobe.com/support/programs/eol-matrix.html