Everything we've learned from 20 years of Salesforce data migrations, distilled into a practical guide. What to expect, what to watch for, and how to do it without losing your data or your mind.
When exit makes sense—and when it doesn't.
Your data rights under Salesforce's terms.
Why Salesforce exits are harder than they look.
APIs, tools, and methods for getting data out.
How long it actually takes, by org complexity.
Mistakes we see organizations make repeatedly.
How to start the process.
This might seem like a strange way to start a guide from a company that does exit migrations. But we've told organizations not to leave. If leaving doesn't make sense, we'd rather say so upfront than take your money for a project that hurts your organization.
Cost has exceeded value. Salesforce licensing costs increase annually. If your per-user cost has climbed to $300+/month and you're using 30% of the platform's capabilities, the math stops working. Especially for nonprofits and mid-market organizations where those dollars directly compete with mission delivery.
You've outgrown the platform. Your data model has been stretched beyond what Salesforce handles well. You're fighting governor limits, building workarounds for features the platform doesn't support natively, or spending more time on Salesforce administration than on the work it's supposed to enable.
Your industry has moved. Purpose-built platforms now exist for verticals that used to rely on Salesforce because there was nothing better. Nonprofit CRMs, healthcare platforms, and financial services tools have matured significantly.
Vendor relationship has deteriorated. Aggressive renewal tactics, surprise price increases, feature deprecation without alternatives. When the vendor relationship becomes adversarial, it's time to evaluate options.
You're frustrated with implementation, not the platform. A poorly configured Salesforce org doesn't mean Salesforce is wrong for you. Sometimes the answer is a better implementation, not a different system.
You don't have a destination. Leaving Salesforce without knowing where you're going is a recipe for landing in a worse situation. Choose your destination first, or at least narrow the field.
Your contract just renewed. If you signed a 3-year agreement last month, start planning now but don't panic. You have time to do this right.
The pain is temporary. Mid-implementation growing pains, a recent org merge, or a team transition can feel like platform failure. Give it 6 months. If the pain persists, revisit.
The good news: you own your data. Salesforce's Master Subscription Agreement (MSA) is clear on this point. Customer data belongs to the customer. Salesforce is a processor, not an owner.
The nuance is in what counts as "your data" and how easy it is to extract.
AppExchange managed package data. If you use managed packages (NPSP, Conga, FormAssembly), the data in their custom objects is yours, but the schema definitions and code belong to the package publisher. You can extract the records; you can't replicate the object structure without rebuilding it.
Platform-generated metadata. Salesforce IDs, system timestamps (CreatedDate, LastModifiedDate), and formula field outputs exist because of the platform. You can export them, but they may not be meaningful in your destination system.
Einstein and AI outputs. Predictions, scores, and insights generated by Salesforce Einstein are derived from your data but produced by Salesforce's models. These typically don't transfer.
Salesforce provides several extraction mechanisms. None of them are complete on their own. A real exit typically requires combining multiple approaches—which is the subject of Chapter 4.
There are five primary ways to get data out of Salesforce. Each has strengths and limitations.
Salesforce's built-in export generates CSV files for all objects. It's free and simple, but it misses attachments, has no relationship preservation, and runs on Salesforce's schedule (weekly or monthly). Useful as a backup, not as a migration tool.
Salesforce's desktop application for bulk data operations. Handles SOQL queries, can export to CSV, and supports the Bulk API for large volumes. Good for straightforward object-by-object extraction, but requires manual handling of relationships and doesn't handle files well.
Programmatic access to all queryable data. Maximum flexibility, but you're building and maintaining extraction scripts. API call limits apply—a large org can take days to extract via REST API alone.
Designed for high-volume data operations. Processes up to 100 million records per 24-hour period. The right tool for large extractions, but requires development effort to handle pagination, job monitoring, and error recovery.
Purpose-built tools (like ours) that combine multiple APIs, handle relationship ordering automatically, manage file extraction, and preserve referential integrity. Higher cost, dramatically lower risk.
We use a combination of Bulk API 2.0, REST API, and custom tooling depending on the data type. Our extraction engine handles dependency ordering (parent objects before children), relationship ID mapping, and file retrieval automatically. All data lands on dedicated encrypted storage during the migration.
How long it takes depends on what you have. Here are ranges based on actual engagements.
Straightforward exit with minimal complexity.
Typical enterprise org with meaningful customization.
Large org with deep customization and dependencies.
These timelines include assessment, planning, extraction, transformation, loading, and validation. They don't include destination system implementation—that's a separate workstream handled by your team or a destination vendor.
After 20 years of migrations, we see the same mistakes. Here's what to avoid.
The most expensive mistake is committing to a timeline and budget before you know what you're dealing with. A $50K migration estimate becomes $200K when you discover 500 GB of attachments, 14 integrations nobody documented, and 3 years of field history that compliance requires you to keep. Get the assessment first.
Your Salesforce implementation partner has a financial incentive for you to stay. Their certifications, partnerships, and recurring revenue depend on the Salesforce ecosystem. This doesn't make them bad people—it makes them the wrong people to run your exit. Choose a vendor with no Salesforce partnerships.
File migration is consistently underscoped. Organizations plan meticulously for record migration and then discover at load time that they have 400 GB of attachments spread across three storage mechanisms. File extraction is slow, storage-intensive, and needs to happen early in the project.
Cutting over in a single weekend feels efficient. It's actually reckless. A parallel run—where both systems operate simultaneously for 2-4 weeks—gives you a safety net. Users can verify data, integrations can be tested under real conditions, and rollback remains simple.
Data is the hardest part, but it's not the only part. User training, process changes, integration rewiring, report rebuilding, and change management all need planning. Organizations that focus exclusively on "moving the data" end up with a technically successful migration and a user base that can't function.
Salesforce access ends when your contract does. If you haven't extracted everything by that date, you're negotiating from a position of zero leverage for an extension. Start the exit process at least 12 months before contract expiration for medium orgs, 18+ months for complex ones.
If you've read this far, you're serious about leaving. Here's how to start.
Before anything else, know what you're working with. Our Exit Assessment gives you a complete inventory of your org, a complexity score, cost comparison, and an honest recommendation. It takes 2-3 weeks and requires minimal effort from your team.
If you haven't already, evaluate destination platforms. The assessment report will help frame what your destination system needs to support. We don't implement destination systems—this keeps us conflict-free—but we're happy to discuss what we've seen work.
With an assessment in hand and a destination chosen, the migration can be planned properly. Field-by-field mapping, transformation specifications, integration cutover sequences, and a realistic timeline. We offer strategic exit planning as a standalone engagement.
Extraction, transformation, loading, validation, and cutover. This is where the planning pays off. Done right, it's methodical and boring. Done wrong, it's a crisis.
Throughout the process, your data is handled according to our data security standards—dedicated encrypted hardware, documented chain of custody, and secure deletion when the engagement ends.
The first step is always an assessment. Let's find out what you're working with.
tyler@colbysdatamovers.com