Split an existing user population

In some situations, you may want to split an application's existing user population into subsets. The resulting subsets each access a user population-specific application built on the original application.

When active cases exist throughout a user population, and there is a mandate to subdivide that user population into two distinct applications, reporting and security become problematic. Cloning the existing database is not the right approach. If the application uses background processing, there is duplicate processing. 

Two of the major deployment approaches are possible:  

• Extending the application by deploying to an existing database 
• Extending the application by deploying to a new database

If you create a new database to support a subdivided user population, and immediate user migration is not required, you can gradually transition user/account data from the existing database to the new database. Ideally, transfer user/account data starting with classes that have the fewest dependencies. For example, attachment data does not reference other instances.

Copy resolved cases for a given user/account to the new database, but do not purge resolved cases from the original system immediately. Wait until the migration process is complete for that user/account. Use the Purge/Archive wizard to perform this task (Dev Studio > Configure > System > Operations > Purge/Archive). Optionally, modify case data organization properties to reflect the new user population.

A requirement to immediately move a subset of an existing user population to a new database is more complex due to the likelihood of open cases. Use the Package Work wizard to perform this task (Dev Studio > Configure > Application > Distribution > Package Work).

The most complex situation is when immediate user population separation is mandated within the same database. To support this requirement, a subset of the existing cases must be refactored to different class names.

Manipulating the case data model for an entire case hierarchy while a case is active is risky and complex. For this reason, seek advice and assistance before attempting a user population split for the same application within the same database.