Hi Victor,
The decision on whether or not to use multi-tenancy really comes down to the difference between the business of the existing groups and the new groups – meaning, what are the functions of these new groups in comparison to the existing groups? Are they being “charged” for services or treated as a separate entity than the existing groups?
Now regarding the complexity of setting up multi-tenancy on an existing system – it is a bit of a complex task as everything now has to be “tenanted” , meaning that existing objects like incident areas, request areas, change categories, templates, surveys, contacts, access types, roles, data partitions etc. all have to be either set to global (meaning valid for all tenants) or set to a specific tenant. It can be a very time consuming process.
The biggest thing to keep in mind regarding the complexity is that once you change a system into a multi-tenanted system, it can be extremely difficult to un-tenant a system, if it can be done at all. So the best bet would be to create a new system to replicate your production system on first, and test out multi-tenancy there first to see if it would met your needs.
Most organizations that use multi-tenancy are using it as a MSP (mass service provider) where they handle tickets for multiple customers, each customer being a tenant on the system, each getting charged separately for delivered services. So if your situation does not really fit that type of model, then you may want to try and avoid using multi tenancy in your environment and use other means of separating these groups and what they have access to etc.
We can help you with that by answering any questions you may have regarding your current situation – so definitely provide some more details about the new or additional groups you are onboarding and we can better answer you as to whether or not Multi-Tenancy would be the right choice for you or not ;)
Thanks,
Jon Israel
Principal Support Engineer
CA Technologies