As part of the team that created the Six Experiences, I can verify that we thought a about EOL as an experience. In the end, we decided that EOL for SW was a mixture of Support and Manage & Upgrade experiences.
EOL is a Support experience because by far the most common SW EOL experience is a SW vendor tells the existing user base, “We will be EOLing Product X by this date. At this time, we will no longer OFFER SUPPORT for this product.” When that happens, a user has three options: (1) self-support, (2) switch to 3rd party support, and (3) migrate to a different offering. If they chose (1) or (2), then we’re really talking about migrating the support service (to ourselves or a 3rd party). This is really no different from a manufacturer of a physical product announcing EOL of support for a product. People keep driving the 1958 Rambler Sedan, even though it’s manufacturer no longer exists. :)
If we chose (3), migrating to a differing offering, then EOL is a Manage & Upgrade experience. However, a migration is not really the same thing as an upgrade (in most cases). So in retrospect, I wish we could have named this experience “Manage, Upgrade, Migrate”.
Note that ‘manage’ encompasses a wide range of experiences. It covers not only managing the SW bits of the app itself, it covers managing all aspects of the data that the app uses. And managing the lifecycle of data is a major industry in itself. There are more data lifecycle management frameworks than you can shake a stick at: https://www.spirion.com/data-lifecycle-management/ ! So under the experience label of ‘manage’, one could have the following set of sub-experiences (just for data!): create, store, use, share, archive, destroy. The last two come into play in thanatosensitive design.
So while I think EOL is an important SET of experiences, I am hesitant to add a seventh experience, when we can deal with EOL issues under Support, Manage, and Update/Migrate. Instead, I would rename Manage & Upgrade to Manage/Upgrade/Migrate.