Project Data Rescue
Last updated: April 2026
A nonprofit organization with 400+ members had contracted with an online CRM company for membership management software. When the software failed repeatedly, they tried to leave. The vendor had mixed their data with other clients' records, demanded an unreasonable payment to extract it, and then delivered corrupt, partial exports with no record structure and fragments of other organizations' data mixed in. PCG negotiated, untangled, purged the foreign data, rebuilt the record linkages from a raw undocumented SQL Server dump, and migrated everything to CiviCRM. No data was lost.
Project requirements
Negotiate with vendor to transfer data. Sort disjointed tables and match key IDs. Discard irrelevant and foreign data. Adapt data to new membership and contact management system. Install and configure CiviCRM. Train staff on new system.
Languages and database
Microsoft Access, Microsoft Excel, SQL Server, Visual Basic .NET, MySQL, Joomla, CiviCRM, Internet Information Services.
Company size
5 employees, 400+ members.
Industry
Non-profit / membership management.
❓ What actually happened to this organization's data?
The client had paid for a packaged CRM system to manage their membership. The software failed. After repeated attempts to resolve the failures with the vendor, the organization decided to move to a different platform. That is when the real problem surfaced.
The CRM vendor had stored the client's data commingled with data from all their other clients in a shared database. When the organization asked for their data back, the vendor demanded payment to extract it. PCG was brought in to negotiate and attempt the recovery. The initial exports the vendor provided were corrupt, partial, had no defined structure, and included login credentials and security keys from other organizations mixed into the records. Establishing record linkages from those exports was impossible. The data was effectively hostage in a system the client no longer had access to and a vendor with no interest in cooperating.
What this situation looks like in practice
Any organization that stores its operational data in a vendor-controlled SaaS system without a clear data portability clause is in this position. The data exists, but accessing it requires the vendor's cooperation. When the relationship deteriorates, that cooperation becomes a negotiation. PCG has handled these recoveries before. The technical work is complex. The negotiation sometimes takes longer than the migration itself.
🛠️ What PCG did to recover the data
After the negotiation produced a raw SQL Server database dump with no documentation and missing key identifier fields, PCG began the actual recovery work. The first priority was identifying and purging every record that belonged to foreign companies before any migration work could proceed. That included sensitive login identifiers and security keys from other organizations that had no business being in the export at all.
With the foreign data removed, PCG worked directly with the client's staff to identify and reconnect as much of their own data as possible given the missing key fields. The convoluted SQL Server schema was mapped and translated to the CiviCRM data model. Export files were built to match CiviCRM's import requirements, the platform was installed and configured for the client's specific membership management needs, and staff were trained on the new system.
The project name, "Project Data Rescue," became official partway through when the scope of what the vendor had done became clear. It was not a standard migration. It was a recovery operation. The organization got their data back, moved to a platform they controlled, and left a vendor relationship that had put 400 member records at risk.
🔍 Technology used
Stuck in a vendor relationship where your data is not clearly yours to take?
PCG has handled data recovery and migration from uncooperative vendors since 1995. The $2,500 diagnostic engagement scopes what is recoverable before any work begins.
Talk to PCG
PCG founded 1995. All project details drawn from PCG's internal documentation. Client identity withheld at client request.
Frequently Asked Questions
This is a situation PCG has dealt with directly. The vendor on this project held the client's data, demanded unreasonable payment for its release, and initially provided corrupt, partial exports that mixed the client's records with data from other clients. PCG negotiated with the vendor, identified which records belonged to the client, purged foreign company data including sensitive login credentials and security keys that should never have been accessible, and extracted what was recoverable from a raw SQL Server database the vendor eventually provided with no documentation and missing key fields. If your vendor is holding your data hostage or providing unusable exports, contact PCG. This is recoverable in most cases, and the first step is understanding what you actually have.
Often yes, but the extent of recovery depends on what is actually present in the raw data. On this project, PCG received a SQL Server database with no documentation, disjointed tables, no defined structure, and missing key identifiers that would normally link records together. The recovery process involved sorting through the table structure to identify which records could be matched by foreign keys, working with the client's staff to recognize their own data, discarding irrelevant records, and reconstructing linkages where the key fields were absent. Not every record was recoverable, but the majority of the membership data was extracted and migrated successfully to CiviCRM. The earlier the engagement starts after a data problem is discovered, the more is recoverable.
The migration process PCG used on this project went from the vendor's SQL Server database through Access and Excel for data cleaning and restructuring, then into CiviCRM via its import system. Each step served a specific purpose: Access handled the table mapping and record matching, Excel managed the data transformation into the format CiviCRM required, and the final imports were validated against the source records before the old system was retired. Staff training on the new system was included as part of the engagement. For a membership organization with over 400 members and only 5 staff, losing contact history or membership status data would have been operationally damaging. The migration was structured to preserve what could be preserved and document what could not be recovered.
The warning signs are usually visible before a crisis. Difficulty getting a straight answer about where your data is stored and how it is isolated from other customers is the first one. A vendor that cannot provide a clean data export on request, or that delays and obstructs when you ask for your own records, is telling you something about how the system is structured. On this project, the data was commingled across clients in a way that should never have been architecturally possible. That is not a data breach in the traditional sense, but it exposed sensitive information and made the client's data nearly unrecoverable without forensic-level extraction work. If your current system cannot produce a clean export of your own data today, that is worth investigating before you need it under pressure.
Timeline depends almost entirely on the condition of the source data and how cooperative the vendor is during extraction. On this project, the timeline stretched due to repeated delays from the vendor providing unusable exports before finally delivering the raw SQL Server database. Once PCG had workable source data, the extraction, cleaning, mapping, and migration to CiviCRM proceeded to completion. For organizations facing a similar situation, the practical answer is: the sooner PCG is engaged, the sooner the timeline can be assessed realistically. What is not recoverable is time spent waiting. Contact PCG to discuss what a data rescue engagement would cover for your specific situation.