nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Reducing number of constituent records before switching to NXT

Janet Davies

We have been hosting RE on our own server since 2008 and will be migrating to NXT hosted by Blackbaud. However, we have been merrily adding constituents the last 13 years because we didn't have size limitations. Does anyone have recommendations on how to archive the records we decide to remove from the database? I'm talking tens of thousands of records. Does anyone have an external database they've used or do you just keep them in Excel?

Find more posts tagged with

Comments

Karen Diener

Are you 100% certain that you are purchasing a “band” or specific number of constituents? Blackbaud has been revising their pricing and many packages allow unlimited constituents. I had this conversation within the last two weeks with a Blackbaud rep when I asked about an additional module for one of my clients - purchasing that module would restructure their contract into the new pricing, which allows for unlimited. It could be due to all of the options they have, but find this out for sure.

If you are in a limited band, look for records that have zero value. That means no gifts, no event attendance, no relationships, no honor/memorial information, no contact information, etc. If you can do that easily, be sure of the results, and delete them globally, then go ahead. I was able to delete over 6000 records from a client's database that moved from self-hosted RE to NXT in March 2021 and there are still more to review. That is less about your record quantity though than it is about not moving junk into the new system.

Bill Connors wrote a paper about this when NXT was coming on to the scene, so I would read through that. It may be out of date if this new pricing structure that Blackbaud is being so quiet about is true, but it is still worth a read.

Karen

Janet Davies

Thank you Karen! We haven't signed anything yet on the pricing, so I will pass that nugget of information on to my VP of Development.

I will definitely read that paper. I'm also trying to decide whether to export and keep the records that aren't current as a back-up, because we know there's always that one person in the office who won't trust the transition to the cloud and want to know where some obscure record has gone. :-)

Karen Diener

I'm also trying to decide whether to export and keep the records that aren't current as a back-up, because we know there's always that one person in the office who won't trust the transition to the cloud and want to know where some obscure record has gone. :-)

Oh, I'm sure that will be the case! Save the Constituent ID, Constituent Import ID, and the record properties (date added, added by, date last changed, last changed by) on that archive file. Along with that, summary fields that show there were no gifts, no event attendance, etc. Chances are very high that the only time you will refer to that file is to verify that someone was removed. “See - they have no information on their record and the date that the record was last changed was 1999”. And chances are probably even higher that you won't need to add them back!

The upgrade is not that hard. Building trust with certain users is!

Karen

Dariel Dixon

I can't state how bad of an idea this is. If the data is in your database, it's there for a reason. If you feel you can then delete a large number of records without impacting the core of your database, then the records probably shouldn't have been added to the database in the first place.

I don't know if you have a plan for data hygiene, but there needs to be some standard for what gets entered into your database.

Tens of thousands of records is a lot. I don't know if the potential savings will not result in more potential problems.

Janet Davies

Yes - there are so many records that shouldn't have been added to the database in the first place. We didn't know about data hygiene when we started the database 13 years ago. We were filling it up with prospect lists, and information from other non-fundraising proprietary databases we run in our office (we are the state office of an international organization.) After years of being told to keep everything, I am finally going through the big clean-up to prepare for the transition to NXT.

We'll get a cleaner database eventually!

Dariel Dixon

Janet Davies:
Yes - there are so many records that shouldn't have been added to the database in the first place. We didn't know about data hygiene when we started the database 13 years ago. We were filling it up with prospect lists, and information from other non-fundraising proprietary databases we run in our office (we are the state office of an international organization.) After years of being told to keep everything, I am finally going through the big clean-up to prepare for the transition to NXT.

We'll get a cleaner database eventually!

I think prospect lists should be in your database, if there is any sort of cultivation happening. I don't know what type of other data is in your database, but I would imagine that data was important enough that someone wanted to keep it for some reason. Whether you were doing any type of reporting or tracking of that data, it's there now. If you were doing any data maintenance on those records like NCOA or the like, you were at least keeping those records somewhat up-to-date. How will that be done with that data if you move it out of the database? If the data isn't being maintained, then is the data outdated anyway?

It sounds like RE was being used as a dumping ground for anything. If you can find a way to quickly purge the “worthless” data without interrupting your data integrity, you should try to do that, but be aware that it may be a difficult route if there is any co-mingling of the data. Removing such a large number of records needs precision to not cause many issues. Make sure you document your plan and steps to remove the records in case something goes awry.

Pruning and deleting data is only good data hygiene. It needs to be done from time to time. I'm in the process of removing old outdated data as we speak. I hope it goes well.