In trying to clean things up and get ready for v11, I've run the check database utility in the toolkit. I had over 6,000 accounts that were missing name information. Of those, I'm left with 1,000 that I'm not sure of what to do with. Some of them are inactive accounts, do I need to reactivate them, correct the names and then re-inactivate them? Or can they just be left alone since they are inactive? What if some of those inactive accounts don't even have names in them (product of poor conversion processes), can they just be left alone and not affect the migration?
Teresa,
Great question. With the data check utility the only three issues which are required to be resolved before the v11 upgrade are the duplicate aliases, duplicate logins, and the null address types. The rest of the issues including the name issue you noted do not have to be solved for v11. In this case if the names are left blank then you will have some constituents with blank first or last names when you upgrade. The good news is that the issue lists will still be intact when you upgrade so those with missing names will be easy to find and you can work on cleaning them up ongoing as folks have time. Frankly the inactive ones I would just leave alone as they are already inactive so they should not get pulled into lists.
Once you are on v11 you can use a SQL script to find the individuals with missing name data and inactiate them in the backend by setting the inactive column to 2 and the inactive_reason column to a valid inactive reason.
I hope that helps.
Anna
Hi guys
I thought it was a great question too, because we were about to ask something similar... plus these....
1. I think the answer to this is Yes, but just to be sure - if we have an inactive constituent with N1/N2 (however partial the data for n2); we'll end up with one inactive Household record, and two inactive individual records, just like for active records, yes?
2. In our current Migration Check Report, there are a squillion (approximately) records showing up with "Corporate Contact (N1N2_Format of IO) has no associations to create affiliation.", which are all (I think) merged records, which of course have no associations because they're lost and alone and ain't got nothin, let alone an Association. I'm presuming we can just ignore those too - Yes? And in fact we should really be only running the report against a List that excludes Merged records, to get sensible results?
Ken
Ken,
Actually the check procedure should probably ignore Merged customer records for that check by default. I'll make a note.
David