To Merge RE Databases or Not to Merge?

Theresa Dougherty

Our agency will be merging with another in 2021. There is ongoing discussion as to how, when and if we should merge our two distinct RE databases into one. Please let me know your thoughts, experiences and Pros/Cons for doing so or not. Any and all comments / recommendations welcome and appreciated.

JoAnn Strommen

If you're truly going to be operating as one agency, my first thought would be to merge them.  

• how will you determine which db to enter a record / gift into?
• if duplication of records between db, will you manually sit and dedup large lists for mailings/solicitations? 
• are you going to keep duplicate records updated in both db?
• if you're using both, you'll need to duplicate every query, report, export to get accurate picture of activity/donations?
• would you be paying BB for each orgs db?

That's like questions with two minutes of thinking. I'm sure there are more.  That said, if you merge, I would pre-merge add an attribute of database source naming the two different agencies.  This way you can tell which org record came from when there are questions. I'm guessing you'll have some merging to do of duplicate records. Have a plan on how you will handle that - especially with gifts.  Be sure you'll have info needed for audits.

Elaine Tucker

I would merge them. However BEFORE doing the merge, I would update your constituent ID's (if possible) to have them indicate the "source". Once you merge them, then all new constituent ID's would have just numbers. I like the constituent ID use because it's "front and center" and not "hidden" in attributes (we have a ton of attributes)

So for example

Database1 - constituent ID = DB01-1001, DB1-1002, etc

Database2 - constituent ID = DB02-1001, DB2-1002,  etc.

After merge - constituent ID = 2020-1001, 2020-1002, etc. 

You can set up all the new cons id's to be automatically generated with a year prefix in business rules.

Veronica Renzo

I would merge, it will be a lot of organizing in the beginning but will be very worth it in the long run.  I agree with the others so clearly mark which database the donor came from and such.  

Carrie Aranda

Our org merged with another one effective January 1, 2020.  One of the first things that we did was merge the two donor databases (although one was not RE).  While we are still cleaning up data (the two orgs tracked donors, gifts, etc very differently), it was the best thing we could have done.  It has allowed us to communicate better with donors and understand which donors/corporations/funders supported both orgs.  I highly recommend the idea of tracking which record came from which database on both constituents and gifts.  For gift records, we added attributes that show which org received the gift.  On constituent records, we added a constituent code to all of the records in the RE database identifying the original org and added a different one to all of the records that came into RE.  This way, as we merged records, fundraisers are able to easily tell which donor/funder supported which org of if they supported both orgs without sifting through attributes.  In addition, we added attributes that tied back to the original database including the ID# they had in the old database.  We are hoping to run reports at 1 year, 3 years and 5 years post-merger on donor retention.


I highly suggest that you begin thinking of how the new org will operate post-merger and develop your database processes and reports to fit.  In our case, it was not just a case of deciding whose processes to keep but how should it be done in the new org.  We went from being two mid-size orgs to one very large organization.  Things like changes in the GL coding (we link directly to FE) all played a part in how gifts and donors are tracked.  It is a great time to start fresh with a new look at how the database is put together.  Almost a year in, and we are still evolving our processes and data management. 

Heather MacKenzie

Elaine Tucker:

I would merge them. However BEFORE doing the merge, I would update your constituent ID's (if possible) to have them indicate the "source". Once you merge them, then all new constituent ID's would have just numbers. I like the constituent ID use because it's "front and center" and not "hidden" in attributes (we have a ton of attributes)

So for example

Database1 - constituent ID = DB01-1001, DB1-1002, etc

Database2 - constituent ID = DB02-1001, DB2-1002, etc.

After merge - constituent ID = 2020-1001, 2020-1002, etc.

You can set up all the new cons id's to be automatically generated with a year prefix in business rules.

Along this same line of thought, I'd use constituent code markers instead of this, which are also viewable the instant a record is opened - a letter to indicate which database they came from, for example. "A - Individual" and "B - Individual" or something like that. I agree that attributes can hide to easily to be the only place you mark something like this, but I like that notes and dates can be entered with attributes.


I've had 2 merges into an existing RE database, and we used constituent codes to mark the different locations and then in the attributes, we entered what former database they came from, what the former record ID# was, and dates, and notes, etc. The Alias field also held the former record ID#.