eTapestry to Salesforce Migration

Posted January 1, 2024 ‐ 5 min read

Data should be portable, and portability should be free

TL;DR: We migrated an organization from eTapestry to Salesforce, and we’ve open-sourced the tool to enable others to do the same.


In the summer of 2023 we started working with an organization called Real Escape from the Sex Trade (REST). REST is a Seattle-based nonprofit that delivers support services to help people find pathways out of sexual exploitation. Their model centers the voices and needs of survivors, and the organization is on a multi-year path to expand their geographic and numerical impact. As they’ve been developing a broader reach, their Customer Relationship Management (CRM) software was holding them back.


Blackbaud’s eTapestry system is a CRM that was acquired by the company in 2006.  In the time since, Blackbaud has positioned eTapestry as an entry-level alternative to their premium offering “Raiser’s Edge”, and offered lower cost usage, and commensurately lower levels of feature development, support, and external integration. In the almost-two decades since, eTapestry has fallen behind the state of the art in CRM technologies, and no longer meets the feature sets that are available in some other CRMs at lower prices.

In addition, eTapestry’s pricing is not transparent, so I’ll describe what I know about it. It charges a low fee for basic usage (which is great), and with that usage it gives its users a small number of records for free (also great). However, it charges increasing amounts for organizations that use more records than their small initial license, meaning that when an organization grows to even a moderate size, and then gets new donors, volunteers, or contacts, Blackbaud raises the price that the nonprofit pays. You can read a plethora of complaints about this on Trust Radius.

Moreover, eTapestry doesn’t have an easily available option to export all data from their systems, and their “ask support for a backup” option requires (at least in the cases we know of) a large payment, a 2-3 month wait time, and an export format that isn’t ready to import into many other systems. You might be asking “how could it possibly take 2-3 months to export data”. We aren’t sure, and were able to program a solution (from scratch, without knowledge of eTapestry’s internal code) to perform an export in just a few hours.

Our Work

REST was facing these problems. They needed to scale their donor base, needed more integration and automation. They were paying more and more money for software that wasn’t meeting their needs. They didn’t have the ability to easily download their data and move somewhere else. The natural choice was to migrate to another system, and REST was searching for a trusted partner to make it happen.

That’s where we came in! We had done some significant work in Salesforce, so we figured a migration from an alternative CRM should be no sweat. Contacts are Contacts right?

It turns out no. While Customer Relationship Management systems might serve similar functions (e.g. rolodex, interactions, and transactions), it turns out that CRM data models differ in the large elements (ex: how are households represented) and in the small ones (ex: how does one address format map to another). As we started to delve into this migration, we recognized that these were challenging, nuanced translations that would require a ton of work to get right.

One of the saving graces of this project was Salesforce’s Sandbox functionality, which allows a developer to spin up a duplicate environment to the production instance, and then make API calls against it. This ability enabled us to quickly try out changes to the data model mapping in a way that was risk-free. We went through 12 rounds of revisions with REST’s staff and volunteers. We would run a new version of the migration code (using a subset of their data), ask them to check it out in a Salesforce sandbox, and they’d come back to us with bugs they’d noticed and things they wanted to be different. Then we would dispose of the sandbox, and try again. Though each cycle of this iteration took about a week (to get feedback and implement changes) the actual upload steps were quick because we wrote the software from the start to be highly automated and minimize manual intervention.

We eventually ran a final export of REST’s data from eTapestry, and ran a final import of it into Salesforce. It was done. REST has been happy with the result, and is now adapting their workflows to Salesforce, building integrations, saving money, and has one less hurdle in the way of them scaling their impact.


This migration was not pleasant. We stepped on a million small rakes during this migration, and it is my greatest wish that nobody else will have to step on those same rakes again. The reason we’re writing about this migration today is to celebrate the launch of the open-sourced version of the code we used to do the eTapestry to Salesforce migration. It has been further generalized from that specific migration, has tons of instructions built into the step-by-step guide, and being MIT licensed and is free to use, redistribute, and even commercialize.

We hope it helps other nonprofits gain more control over and utility out of their data. If you’re a nonprofit trying to make a similar move, check out the code, and if you need a trusted partner to help you through the process, Silicon Ally is always here to help.