We have a use case where we need a separate development tenant because of situations where some development efforts are not ready to go to production and others are, but the dev2prod feature is not granular enough to facilitate this with, for example, "include offering X but not offering Y in dev2prod".

To work around this, we would use a separate development tenant, where 1 tenant is only for development efforts expected to go in the next dev2prod, and the other is for efforts not set to go in the next dev2prod, POCs and other things.

This workaround creates additional problems, though:

• To be effective as a POC or dev tenant, any changes in the other tenant that are also in production need to be manually backported somehow to this additional dev tenant, constantly creating challenges to keep the tenants aligned
• If the other dev tenant has native SACM, the additional dev tenant will also need to have native SACM and its own CMS with similar config and data, otherwise it is not a true test/dev environment similar to the other dev and prod

This doc reference https://docs.microfocus.com/doc/SMAX/24.2/TenantClone carries the title "tenant clone", but actually talks about "from one suite instance to a different suite instance". What I am interested in, is cloning to the *same* suite instance. 

Theoretically, in the absence of more granular control over dev2prod (like we would have in a coding development scenario where we would use Git and create feature branches, cherry picking those items we wish to merge into master as a production release on a weekly basis), I would like us to be able to quickly clone a dev tenant to another copy of itself in the same suite instance, replacing an existing tenant, as a way to keep providing a fresh dev/test/poc tenant that mirrors the other dev (and prod) for doing development that is not going to be ready/approved for our next weekly dev2prod (e.g. offering 'x' but not 'y'). This would have to be relatively quick and simple, perhaps able to be automated, so we could do it frequently, because otherwise this tenant will fall out of alignment with the dev2prod dev and prod tenants.

In another organization, comparitively, with a different ITSM toolset, we had a similar challenge in that our separate training instance would quickly fall out of alignment with production, so would lose its effectiveness as a proper training instance. Our solution, which the toolset allowed for, was to set up an automated solution where our training instance was automatically destroyed every weekend and a fresh export of production was cloned, becoming the new training instance.

From what I've been able to learn from working with SMAX the last several years, this is not easily achieved with this toolset.

Would anyone have any advice on how to overcome the limitations of dev2prod I mentioned in our use case, so that we can have this:

1. Suite instance 1 with production tenant 1
2. Suite instance 2 with development tenant 1 for controlled week to week dev2prod development, development tenant 2 for POCs and longer term development that isn't ready for this week's dev2prod (but that does not lose alignment with the successful dev2prod actions happening between the controlled development tenant and production (also keeping in mind that we use native SACM in the controlled tenant but the other tenant does not because we have not explored whether we could set up a 2nd CMS customer ID without incurring additional infrastructure/licensing costs in dev)

OR

1. A way that a single development tenant can be used as a dev2prod platform by somehow excluding granular items that are not ready to go to production (for example, offering X is ready but offering Y is not)