Expand my Community achievements bar.

Submissions are now open for the 2026 Adobe Experience Maker Awards.
SOLVED

AEM as Cloud service | Content updation in prod through package or manual updation

Avatar

Level 4

Hi Team,

As part of our production deployment process, we often need to update content changes. I would like to understand the best practices for handling content deployment from stage to production.

  1. What are the recommended scenarios for pushing content packages from stage to prod?

  2. In which cases should we update or create content manually in the production author instance?

  3. Sometimes, teams share content packages that are not well-scoped and contain hundreds of child nodes or many child properties.

My concern is: if we replace entire nodes during package installation, could this cause any issues in production? Also, if a node or property does not get updated or replaced as expected, what are the best ways to identify or validate such discrepancies?

Any guidance or best practices on this would be appreciated.

Thanks

1 Accepted Solution

Avatar

Correct answer by
Level 5

Hi @georhe6 ,


It is not in the best practice to move pages from stage to prod on regular basis. This might cause unexpected issues, any custom development which adds environment specific properties will mess up the production content,
To your questions 

  1. Fist time when there are no content in prod and authors can create content on stage and move to prod or when there is a content tested and created using any new components during development. This is mostly due to urgency of page creation.

  2. All the time content should be directly updated/created on prod. You can leverage the preview feature to verify page before publishing or use workflows to approve page publishing so as to avoid publishing wrong contents.

  3. Take a backup of the node or content that you need to override and install package and if anything goes wrong uninstall the package and install the backup package.

 

View solution in original post

2 Replies

Avatar

Community Advisor

Preferably donot plan for content propagation from lower environment into production that ll blindly replace live content. Keep lower environments for IT teams like dev, QA, testing, performance etc. And spare production to marketing, business team only. But many times this is difficult to strictly follow. 

 

  • When new components or templates are created, that requires launching new pages, not touching existing content, its fine to package and ship new content from lower to prod.
  • When existing components are enhanced that requires updating existing pages, preferably plan to manually edit content at production instead of packaging from lower 
  • Risk is, stage may easily get out of sync from prod. We may accidentally push an obsolete content, polluting production
  • When content updating is massive requiring 100s of pages to update, it may not be feasible to manually edit at production. Such big content updates should be planned well. Callout outage to content updates. Request authors to halt content curation. Downsync prod to stage. Perform content edits manually/scripted. Prepare package of affected nodes only. Ship back to prod and resume curation. 
  • Even if there is automated daily content downsync process, still its not advisable to ship content from lower to prod, unless you're editing large volume. 

Avatar

Correct answer by
Level 5

Hi @georhe6 ,


It is not in the best practice to move pages from stage to prod on regular basis. This might cause unexpected issues, any custom development which adds environment specific properties will mess up the production content,
To your questions 

  1. Fist time when there are no content in prod and authors can create content on stage and move to prod or when there is a content tested and created using any new components during development. This is mostly due to urgency of page creation.

  2. All the time content should be directly updated/created on prod. You can leverage the preview feature to verify page before publishing or use workflows to approve page publishing so as to avoid publishing wrong contents.

  3. Take a backup of the node or content that you need to override and install package and if anything goes wrong uninstall the package and install the backup package.