Inscrutable Inactive Implications

Silly question, perhaps: If we have a v10 record that is inactive, the conversion process appears to create a household record complete with two new affiliate records and makes them all inactive. Our Development contact has asked about the efficacy of generating so many records that are not quite as useful to us being that they're inactive (in some cases, deceased).

Is the general logic to keep these records for historical purposes, or is there some conversion default setting that will allow us some control over who gets processed into v11?

Thoughts? Suggestions?

Thanks, Tessiturians.

Parents
  • Hey there Matt,

    One of the main goals in the migration was to make sure you did not lose data.  If an inactive constituent has both a Name 1 and Name 2, if you do not migrate to a household and create individuals you are going to lose the name 2 data as well as any N1/N2 granularity assigned to the record.  For that reason we do not have an option of skipping household creation on inactive records.  If you as an organization do not want to migrate inactive records to households, with the understanding that you will lose the Name 1/Name 2 granularity for any data on the record, the easiest course of action is to remove the name 2 from the inactive v10 individuals so they do not get picked up in the household creation.  You may want to consider using the name 2 to create an alias on the record before you remove it from the constituent record.  

    Depending on how many you have you may opt to do this manually by creating a list with constituent type IN individual constituent types, Inactive = Yes, LName2 Exists IN Yes.  This will give you all the inactive individuals with name 2 data and you can manually change them.  

    Alternately you can take the SQL out of the list using manual edit and create a script to generate the alias, and remove the name 2.  Use this option if you have more than a few constituents to change.  

    In either case, this should be on your pre-upgrade checklist to do once you close the users out before you upgrade.  

    Best,

    Anna

Reply
  • Hey there Matt,

    One of the main goals in the migration was to make sure you did not lose data.  If an inactive constituent has both a Name 1 and Name 2, if you do not migrate to a household and create individuals you are going to lose the name 2 data as well as any N1/N2 granularity assigned to the record.  For that reason we do not have an option of skipping household creation on inactive records.  If you as an organization do not want to migrate inactive records to households, with the understanding that you will lose the Name 1/Name 2 granularity for any data on the record, the easiest course of action is to remove the name 2 from the inactive v10 individuals so they do not get picked up in the household creation.  You may want to consider using the name 2 to create an alias on the record before you remove it from the constituent record.  

    Depending on how many you have you may opt to do this manually by creating a list with constituent type IN individual constituent types, Inactive = Yes, LName2 Exists IN Yes.  This will give you all the inactive individuals with name 2 data and you can manually change them.  

    Alternately you can take the SQL out of the list using manual edit and create a script to generate the alias, and remove the name 2.  Use this option if you have more than a few constituents to change.  

    In either case, this should be on your pre-upgrade checklist to do once you close the users out before you upgrade.  

    Best,

    Anna

Children
No Data