Authoring in Stage vs Prod?

Hi, 

Here are my two cents: Although your Stage environment should ideally be a copy of Prod, this isn't always the case. Therefore, authoring directly in Stage is not always recommended. However, there are certain conditions where this approach can be viable.

In general, it's not considered good practice to promote content from lower environments to Production due to the potential for human errors. For those on AMS, interaction with the Package Manager in Production is typically not allowed unless explicitly approved by Adobe through an exception process. Similarly, AEMaaCS lacks a clear method to move content from lower environments to Production, suggesting that the preferred approach is to author in Production and then propagate content downwards.

Regarding content freeze scenarios, in my opinion, these should not occur frequently. If they do, it may be necessary to revisit the timing of these freezes within your deployment and development cycle. Another strategy to mitigate content freezes is to limit them to specific paths, hence you can create content outside the content freeze area. Lastly, consider using Launches, which can be helpful in such scenarios as well.

Hope this helps.

@nicholeve 

Depending on the industry, you may find:

1. Content created in Stage and promoted to Production
2. Content created on Production and Stage used for UAT.

Majority of the customers use the Option-2.

• This allows Dev activities to continue in Dev, while Stage is used for UAT/Trainings etc.
• This is also a recommended set up from Adobe, until you need Option-1 for specific reasons.
• You might no longer need Content Freeze windows.

My 2 cents: PROD and Stage are 2 different types of environments, and their role differs mostly in these aspects:

• A PROD environment  usually has a much higher SLA and you have monitoring and active alerting & incident handling for it. That's different from stage. When your content creation process uses the Stage env as an integral part of it, you need the same amount of SLA and monitoring for it. That means from an operational point of view your Stage env should be considered as an additional PROD environment. It's critical for content creation & maintenance.
• The roles of Stage and PROD typically relates to code lifecycle; you do your final validation and testing on a Stage environment, before you deploy it to PROD. If both environments are critical to your content production, you cannot use Stage for that final release validation role anymore, you need to do this on a different environment.
• The content livecycle is different, and should not be required to validate it the same way as you need to validate code; it's easier to change, and it should be straight forward to change content without the need to do another deployment.

(In the context of AEM as a Cloud Service you are encouraged not to use your Stage environment as an integral part of the content creation process; IIRC for Stage there is no SLA, and also the alerting standards are much different on Stage than on PROD environments.)

The practice utilized in our projects involves using Production environment for content population activities. If the case of Multi-language site, the translation process is also carried out in production environment. 

Staging environment serves as a replica of prod (often without the full actual content) and is maintained for UAT and functional testing, while the content validation is conducted on the prod environment.

@nicholeve Did you find the suggestions from users helpful? Please let us know if you require more information. Otherwise, please mark the answer as correct for posterity. If you've discovered a solution yourself, we would appreciate it if you could share it with the community. Thank you!