Broad Consideration for LRL Content: more clear language for replacement and deprecation

• Type: New Article
• Status: Open
• Priority: Minor
• Resolution: Unresolved
• Fix Version/s: master
• Component/s: Website
• Labels: None
• Type of Documentation: User

Split ticket LRDOCS-10173 into this ticket

Task: (on LRL site as a whole) Review documentation language around replacement of our deprecated apps, to see if we can be clearer.

Slack thread for context:

Comments from joel.garman:

"Typically as part of the release process https://issues.liferay.com/browse/RELEASE-3167

1. I would not assume that if a replacement is identified for a feature it implies that a data migration path is present
2. I also would not assume that replacement has bearing on the future availability of the feature. Basically, replacement doesn't dictate if the feature will or will not be available
Like Russ said, it would be ideal if the term "replacement" or "replaced" had implications for data and future availability but it doesn't.

I think what would help is to identify if there is a data migration path or not. This way the customer could properly plan for their upgrade and understand the level of effort it would take to move from X to Y feature or if they need to

Russ: For the data migration question, maybe #t-dxp-bravo would be the place to ask? [Although Luiz might know, and is probably seeing it here too]

Joel: Technically, according to the deprecation process data migration is needed in order to archive a feature or module so that we don't leave orphaned data in the DB, but that's not always followed