Advice Needed on Mergers (not merging records)

Sara, while we've never done a full merger, we have "absorbed" other orgs' or departments' contacts into our own RE system, either due to fundraising collaboration or because of assuming management for a fiscally dependent foundation. Here are some thoughts:

• Who to talk with: definitely, as you said, your finance team and your IT staff. Also, the absorbed org's fundraising/database staff or database company support team. In assimilating donors from another software system in the past, I have had to reach out to their company support for more comprehensive data exports that were unable to be outputted from the user interface.

• To that end, also do not terminate their database subscription immediately. Give yourself 3 months or so of overlap so that you can analyze their existing structure and if necessary request additional exports and software support.

• To retain donor history, you will likely be required to make new Funds, Appeals, donor Attributes (Custom fields), and Solicit codes at the least. You may also, depending on your plan for blending communications, need to make additional Phone & email types, Constituent Codes, & Action types.

• Strongly recommend importing more than just basic contact info and gifts. If possible, you want relational history as well, such as actions and mailed appeals. This will require potentially several rounds of Imports, as you will first need to import the constituents, and then import linked records such as assigned appeals and actions. Be aware that other databases (especially poorly maintained ones) may have stuffed this data into all sorts of weird spots. Another reason to preview their original database intact, so you can see how they were using it, rather than simply working off a raw cvs file.

• Important: create a custom field to retain the previous software's constituent ID. This is useful for cross-referencing any random cvs files, mailing lists, or other associated files that come to your team aside from the regular database imports. This field, as well as a unique Constituent Code and some solicit codes, will also allow you to suppress and target them with specific communications more easily in your actions and appeals strategies. For example, you may not want to dump them into your regular mailstream at first. You may wish to keep their branding separate for a time, create an onboarding track to introduce these donors to the newly blended org, or target them for funds and interests that were specific to the previous organization's campaigns.

• Be aware of trouble spots that may not be adequately outputted in a raw cvs file or may make for difficult importing: incomplete pledges with balance due, linked constituent spousal and contact relationships, soft credited gifts, gifts that are not soft-credited that should be (such as DAF gifts posted under the DAF company's record rather than the sponsoring donor's record), split funds or appeals, write-offs and adjustments, etc.

• Expect messy data. Every other database that I've had to process was horribly messy. Expect potentially hundreds or thousands of duplicates, depending on the size of the new data file. One small donor file I processed had a donor entered 17 separate times. Another file of 300K records that I have been helping to migrate has tens of thousands of potential duplicates that we are still sorting through. Plan cleanup time - deduping, address updates, and deceased finders - into your onboarding plan.

I'm sure there are other considerations that I've forgotten to mention. The important thing is that you're planning ahead. Good luck!

Good advise from the others.

I would also add beforehand to make sure the other database is clean and to fix any issues/problems in that database first before dumping it into your database. Making sure dupes are merged, etc. Make sure that database is cleaned up as best as you can before you merge it with the other your database. This is where you get to see how a mess other databases are because of poor protocols/procedures, people not knowing what they are doing and not maintaining a good database.