Getting ready for Next Gen

Hi Dave,

Thanks for the questions and congrats on the smooth upgrades.  Some answers for you.  This is based on what we know now, and usual caveats that we are in the process of analyzing and coding this, so it could change by the time we reach general release.  I should also point out that in answering some of the below questions I am using some Version 11 terminology that hasn’t yet been distributed in documentation (but is coming soon!).    If you need clarification on the terminology past what I provide below, I’m happy to help out or possibly ask that you wait until the documentation comes out in the next month or so. 

Here are our replies:

• How will the constituents be imported from our current database? 

First to clarify, there is no move from one database to another.  As with any previous Tessitura upgrade, in Version 11 the existing database will have scripted changes and additions, but there is not a new database.  As for the upgrade process, no accounts will be removed.  All existing accounts will remain with their existing account numbers.  Accounts that do not have a Name2 on them will remain more or less as they are today.  Accounts that currently have both Name 1 AND Name 2 will change to a Family or Household-type account, with much or all of the information residing on that Household account (as it does today).  For those records that currently have both a Name1 and Name2, new accounts will be created for those individual names, and affiliated to the Household account. 

As noted in our January webinar, the upgrade process will clearly be much more involved than past upgrades.  Included in the upgrade steps will be a series of business decisions around how to upgrade your constituent data to fit the new model.  There will also be opportunities during the upgrade process to include your own organizational custom code, should you wish to add more of your own business logic into the upgrade process.

• Will current constituents that have both Name 1 and Name 2 be converted to a family account and the individuals given new personal ids?

Yes, see above

• Or will all current ones be transferred as they are and then moving forward, family accounts can be created?

In order to retain distinct information about each of the new individuals created, the household-creation for existing Name1/Name2 accounts will happen during the upgrade.

• If they are automatically converted, can we pick and choose which ones get the conversion?

We are making a fundamental change in how a constituent is built and how they are related together.  In essence, the “Name2” functionality won’t exist.  As a result, if we didn’t create the family+individuals at the time of upgrade, you would risk losing N1 and N2 data entirely.  We are happy to discuss further…

• If we convert to a family account, can they ever be split up again in the future if need be?

Post-upgrade, a formerly Name1/Name2 account will have three accounts – the Household/Family account, and two individuals, one each for Name1 and Name2.  They will be linked together using an Affiliation which is a style of relationship similar to Associations.    You could remove the individuals from the family account by removing that Affiliation. (Or add new Affiliates, etc.)

• If account is split, does it divvy up the info according to which “id” was assigned to it? e.g. phone numbers with their personal id, etc.

For any area in Tessitura that currently has a Name1/Name2 flag, the upgrade script will move that item to the newly created constituent. (So, for instance, if you currently have a Constituency code of “Volunteer” that has the Name2 flag on it, this constituency code would leave the household account and move to the “formerly Name2” individual that is created during the upgrade.)  We also recognize that there are times when areas of the system that don’t have a Name1/Name2 flag are routinely used to indicate which name on an account “owns” that data – such as Phone Types, Eaddress Types, etc.  The upgrade process will allow an organization to choose to move these items to the new constituents as well, if you wish.  Otherwise, all data will remain on the Household account.

We will be releasing detailed documentation surrounding this process in the coming months, as well as having a session on the V11 upgrade at TLCC2011. 

Thanks for the questions and please let me know if you have others…

Andrew

Hi Andrew, 

A question I have is will there be any type of reference to the old customer number after the split?

Thanks,

Jon

Andrew,

I forgot to ask how will logins be handled when the account gets split to individuals?

Thanks

Hi Jon,

Yes, through the front-end you will be able to see in the General Tab and Relationships Tab that an individual is the first affiliate on the household and the second affiliate on the household - essentially mirroring that they were previously Name1 and Name2.  You will see the individuals on the General Tab of the Household and there will be a new navigation tree that will show the affiliates of the household.  From a data perspective, we are expecting to have a table that maps the original customer_nos to the newly created individual constituents (although this table won't be visible through the application).

On the logins question, the default behavior would be to leave them on the household account unless the N1/N2 flag has been set to Name1 or Name2, in which case they would move to the appropriate new individual.  As mentioned before, we expect to have areas in the upgrade script to add business-specific logic, so for instance, some organizations might make the decision to leave logins on the household regardless of the N1/N2 flag.

Hope that helps!

Andrew

Hi Jon,

Yes, through the front-end you will be able to see in the General Tab and Relationships Tab that an individual is the first affiliate on the household and the second affiliate on the household - essentially mirroring that they were previously Name1 and Name2.  You will see the individuals on the General Tab of the Household and there will be a new navigation tree that will show the affiliates of the household.  From a data perspective, we are expecting to have a table that maps the original customer_nos to the newly created individual constituents (although this table won't be visible through the application).

On the logins question, the default behavior would be to leave them on the household account unless the N1/N2 flag has been set to Name1 or Name2, in which case they would move to the appropriate new individual.  As mentioned before, we expect to have areas in the upgrade script to add business-specific logic, so for instance, some organizations might make the decision to leave logins on the household regardless of the N1/N2 flag.

Hope that helps!

Andrew

Yep Thanks!