If your organization is in the midst of migrating its databases to another system, there is a good chance that your office is littered with clumps of hair and tissues. Employees of organizations considering a migration might fear a similar fate.
Leaders in the field shared their successes and hardships during “The Good, the Bad and the Ugly: Things to Consider When Planning a Database Migration” during DMA’s 2016 Washington Nonprofit Conference. The program offered a step-by-step tutorial on what to consider, how to approach and what to prepare for when it comes to migrating organizational data, an oft-draining, complicated process.
A database migration is not something an organization should change for the sake of change, according to Alicia Meulensteen, vice president, direct response and stewardship at ASPCA, headquartered in New York City. Budget and staffing and resource should be considered. Can your existing team handle the extra work? Will outside partners be needed? Necessary timeline and time remaining on an existing contract must also be considered, Meulensteen said and, no, those two factors are not synonymous.
Catherine Ewald, director, revenue database/operations at the International Rescue Committee (IRC) in New York City, added that a system going to sunset is a common reason for migration. When selecting a new system, ability to synchronize with existing CRM and payment-processing software, the need for remote or local servers, ease of use, and, in IRC’s case, ability to handle a variety of international currencies are factors to consider. Meulensteen emphasized stability as another important factor. Could your new provider potentially be bought out by the provider you just moved away from?
Once the why and who are settled, here are some of the tips panelists provided to help ensure a smooth transition:
* Come up with a sample timeline. Migrations, start to finish, typically take between 12 and 18 months to complete, not including an additional year or two for refinements, according to Meulensteen. Do not feel as though you have to force something and do not launch with a half-baked database. ASPCA leaders extended timelines during their recent migration and Ewald, likewise, emphasized the importance of staying flexible and building space for roadblocks into a timeline.
Try to secure a buy-in among staff. The process is seldom easy, but well worth working toward, according to Steve Alexander of Alexander Strategies. Educate staff on the migration and set expectations. Understand and convey during the buy-in process that, while a migration might help facilitate the raising of more money, it far from guarantees it.
* Engage key stakeholders in the process. ASPCA had a group of about 10 employees who helped guide the migration throughout the entire process, according to Meulensteen, including analytics, stewardship and major-gifts staffers. Look at new and existing hires. Will job descriptions change post-launch? Will new positions be needed? Hire necessary future staff as early as possible, Meulensteen recommended. It might seem like you are paying someone for work that isn’t being done yet, but an early hire could lead to better long-term efficiency. Ewald was involved in the mapping and integration process of IRC’s migration. She recommended bringing someone on to tend to the day-to-day necessities of the migration.
* Know that the process doesn’t stop post launch. Ewald recommended coming up with a testing plan for the new system based off of key functions to be used. IRC did not run parallel systems shortly after launch, but recommends checking whether it would be possible to extend existing service long enough for an overlap. Alexander, too, recommended having an overlap.
* Keep the conversation going. Set up a stakeholder group to keep the lines of communication open. Prepare to have a backup if things don’t go well. IRC had to make do with being unable to send out acknowledgements for a month after its migration or report for three months after migration. Consider all possible scenarios.