Intended Use of the AEM 6.5 LTS Analyzer Content Transformer | Community
Skip to main content
AEM_Dan
AEM_Dan
Level 3
April 14, 2026
Question

Intended Use of the AEM 6.5 LTS Analyzer Content Transformer

  • April 14, 2026
  • 1 reply
  • 8 views

The LTS Analyzer identified a handful of references to obsolete components in our custom code, which we remediated and were removed from the report on a subsequent run.

What remains are many paths to out-of-the-box components that we have never used or referenced.  In our dev system, I used the Content Transformer to remove ALL paths (/content, /etc, /libs, /var) on both author AND PUBLISH instances, PRIOR to upgrade (6.5 SP21).

After upgrade, everything is working fine.  Zero issues.  But now I am seeing conflicting information that the tool should not be used that way, specifically:

  1. Only /content and /etc paths should be removed by the Content Transformer.
  2. The Analyzer should only be run on author instances.  On publish instances you should remove the obsolete paths manually or some other method (not sure what that would be).
  3. And just to confirm, the Content Transformer must be run on a 6.5 classic instance, prior to upgrade.  It errors out on a upgraded LTS instance.  The error logs indicate something about a java version compatibility issue.

Thank you! 

1 reply

S
Adobe Employee
SubbaraoGa1Adobe Employee
Adobe Employee
April 14, 2026

​@AEM_Dan 
Thank you for your careful work preparing for your AEM upgrade and for your follow-up questions regarding the usage of the LTS Analyzer and the Content Transformer.

Summary of Recommended Practices

  • Content Transformer Usage:
    The Content Transformer should be used only on the /content and /etc paths in your author environment, and strictly prior to upgrading your system (e.g., before applying 6.5 SP21). It should not be used to clean up /libs or /var, as modifying these out-of-the-box/system paths can cause repository instability after upgrade.

  • Publish Environments:
    The Content Transformer and Analyzer are intended for author environments. For publish instances, obsolete paths should be removed manually or by republishing clean content from author rather than using the Content Transformer. This ensures consistency and avoids introducing upgrade risk.

  • Tool Compatibility:
    The Content Transformer is supported for use on classic AEM 6.5 author environments, prior to upgrade, and with the Java version required by the tool (typically Java 8). Attempts to run it after upgrading (such as on an LTS instance) may result in Java compatibility errors.

Your Observations

Since your test shows no issues after upgrade—even after content path removal on both author and publish—no immediate corrective action is needed. However, for future upgrades or projects, we recommend following the best practices above to avoid any potential issues.

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/migration-journey/cloud-migration/content-transformer/overview

https://experienceleague.adobe.com/en/docs/experience-manager-learn/cloud-service/migration/moving-to-aem-as-a-cloud-service/content-migration/content-transfer-tool

https://experienceleague.adobe.com/en/docs/experience-manager-cloud-service/content/migration-journey/cloud-migration/content-transfer-tool/guidelines-best-practices-content-transfer-tool

 

    AEM_Dan
    AEM_DanAuthor
    Level 3
    April 14, 2026

    Thank you for the detailed explanation.  Follow-up:

    • Then how are /libs and /var cleaned up?  Or do they just continue to exist in LTS?
    • I should have mentioned this, but we have on-prem and AMS instances, not cloud service.  I assume the recommendations are the same, but those documentation links don’t apply.

    I should also mentioned the documentation does NOT mention ANY of these constraints.  One would just assume the Content Transformer should be run on all paths and all instances.

    https://experienceleague.adobe.com/en/docs/experience-manager-65-lts/content/implementing/deploying/upgrading/aem-analyzer

     

    S
    Adobe Employee
    SubbaraoGa1Adobe Employee
    Adobe Employee
    April 14, 2026

    ​@AEM_Dan You’re right: the AEM 6.5 LTS Analyzer docs you linked are focused on detection, not on how to remediate every path type or where to run tools. The migration/CTT/Transformer docs are mostly written from an AEMaaCS point of view and don’t map 1:1 back to on‑prem/AMS LTS upgrades, which is what you’re doing.

     

    • The LTS Analyzer runs against the whole repository and shows where deprecated/obsolete features exist, including under /libs and /var.
    • Product areas like /libs are updated only by Adobe’s LTS/service pack installers; You must not delete or refactor them yourself. Your job is to stop using those deprecated features in our custom code and content.
    • Your content under /content, /apps, /conf is what we clean up with tools and scripts.
    • On‑prem and AMS follow the same principles; the Cloud Service docs around Content Transfer/Content Transformer highlight the safety boundaries, but the concepts apply equally to LTS upgrades.

      https://experienceleague.adobe.com/en/docs/experience-manager-65-lts/content/implementing/deploying/upgrading/aem-analyzer
    Terms & ConditionsAccessibility statement

    Loading footer...