Switching from ChurnZero starts with a cost nobody mentions in the renewal conversation: ChurnZero’s REST API is a paid add-on. If your account does not have it enabled, the complete route out of the platform is not available to you, and what remains is screen-by-screen exports from the interface.
That single fact reshapes the project. Ask your ChurnZero CSM whether the REST API add-on is on your account before you plan anything else, because the answer decides whether this is a connection or a fortnight of CSV assembly.
What follows is an object-by-object account of what ChurnZero’s API will and will not give up, written while building an importer against it. It is useful whatever you are moving to.
Why there is no guide to this
Search for how to leave ChurnZero and you will find a click-through tutorial for exporting one screen at a time, a migration vendor’s sales page, and ChurnZero’s own feature page for the API. There is no published account of what actually comes out.
That is not unusual. No platform documents its own exit, and the companies that write migration content are selling the destination. The result is that teams scope this project on assumptions and discover the gaps in week three.
What you need enabled before anything
Three things, and your ChurnZero admin controls all of them.
The REST API add-on, as above. Paid, and not on every account.
An API user with the Developer Tools permission. The API key belongs to a specific user, and that user needs this permission or the key will not authenticate.
Bulk Read permissions, set per object on that user’s permission group. This is where most migrations stall, because the permissions are granular and the consequences of missing one are not obvious.
| BULK READ PERMISSION | WHAT IT RELEASES |
|---|---|
| Accounts | Your companies. Required |
| Contacts | Your people. Required |
| User Accounts | The owner on each account |
| Notes | Notes |
| Meetings | Meetings |
| Messages | Emails |
| Tasks | Open and closed tasks |
| Surveys | Survey responses |
| Churn Scores | ChurnScore history |
Grant Notes, Meetings, Messages and Tasks together. If only some are granted, a read that reaches a missing one stops rather than skipping it. Every other permission is optional and leaving it off simply leaves that data behind.
You will also need the ChurnZero URL you sign in at, including the region segment, in the form. The API key itself is created in ChurnZero’s admin area under API Keys.
What the API gives you
Accounts and contacts. Your companies and people, with custom fields on accounts.
One consequence worth planning for: ChurnZero does not send a website on an account. There is no domain to match on, so accounts arrive as new records rather than merging into companies you already have elsewhere. If you are moving into a system that already holds some of these customers, expect to reconcile rather than merge.
Owners. The user who owns each account, assuming you granted User Accounts.
Notes, meetings and messages. These are your activity history. Meetings keep their owner as the author. Notes come through without an author at all, because the API does not say who wrote them. Messages arrive as emails with the sender attributed when a ChurnZero user sent it; announcements and internal emails are excluded.
Tasks, open and closed. Note that ChurnZero tasks carry no risk or escalation flag, so nothing arrives pre-marked as urgent on the other side.
Survey responses. NPS, CSAT and CES, with their original answer dates. Responses to custom survey types do not come across, because ChurnZero records every custom response as “completed” rather than with a rating, so there is no score to carry.
ChurnScore history, where your instance has kept it. Up to two years, one point per week. Some ChurnZero instances store only the current score for each account, in which case there is no history to take.
Contract values and renewal dates. Total contract amount and next renewal date per account.
The currency problem
ChurnZero does not record which currency its amounts are in. Not on the account, not on the value.
This matters more than it sounds. Any system receiving that number has to be told what it means, and if you are exporting to a spreadsheet you need to know it yourself before the figures are used for anything. A total contract amount with no currency is a number, not money.
Plan for a single decision on currency across the whole export, and check it against a handful of accounts you know.
What stays behind, and why
This is the half that decides your timeline, and every item has the same cause: the API does not expose it.
| WHAT STAYS | WHY |
|---|---|
| Plays and alerts | The API does not expose them at all |
| Journeys | Readable, but they do not map to another system’s automation |
| ChurnScore factors | The API lists each factor’s name and type, but not the points it carries or its thresholds |
| Segment criteria | Segments are listed by name, without their filters |
| Success plans | There is no success plan object. Tasks on a plan come out as ordinary tasks |
| Survey definitions | Your surveys are listed, but only the responses export |
| Note authors | The API does not record who wrote a note |
| Draft notes | Unpublished notes are private to their author |
| Product subscriptions | No subscription history, and subscriptions carry no price |
| Product usage events | Stored as event rows, often millions of them |
| File attachments | Not exposed |
| Custom tables | Readable, but not part of a standard import |
Read that list as one sentence: your records leave, your logic does not.
Scores come out as numbers without the model that produced them. Segments come out as names without the rules that fill them. Plays do not come out. Whatever you move to, the scoring and automation are a rebuild, and that is the part worth scoping honestly rather than the data.
The exception is product usage, and it should not move anyway. Usage belongs to your product or your warehouse, and piping it into a CS platform and then out again is a detour. Rebuild that connection at the source.
The rate limit you share with everything else
ChurnZero applies one per-minute API limit per instance, and every tool reading through the REST API shares it. If you have a reporting connection running, to Power BI or anything similar, it competes with your export.
Two practical consequences. A large export can take longer than the object count suggests. And an export running at full tilt can slow the reporting everyone else depends on, so it is worth telling whoever owns those connections before you start.
The route without the API
If the add-on is not on your account and you cannot get it added, you are exporting from the interface, one view at a time.
That is viable for accounts and contacts. It is poor for anything with history, because an interface export gives you the current state of a record rather than the trail behind it. Expect to lose activity history, score history, and the original dates on survey responses.
If your contract is ending and the add-on is the only thing standing between you and your history, it is worth raising during the renewal conversation rather than after it. Access to your own data has more leverage attached to it before you have signed off than after.
What this costs in time
Two numbers get quoted for a migration like this, and they are not measuring the same thing. The export takes days. The move takes months. Almost every plan prices the first and discovers the second.
What the days are
Getting your data out of ChurnZero is a read, not a project. Your admin enables the add-on and grants the permissions, which is an afternoon if the right person is free and a fortnight if they are not. After that the API is paced to stay under ChurnZero's rate limit and runs on its own.
There is genuinely no craft in this part. If someone is quoting you weeks for the extraction, ask what they are doing with the time.
What the months are
The months are not technical. This is the part worth understanding before you sign anything.
Nothing you configured comes out with its rules attached. Your ChurnScore arrives as a column of numbers, not as the model that produced them. Your segments arrive as names, not as the filters that fill them. Your Plays do not arrive at all. So on the other side you are not re-entering settings, you are re-deciding them.
That is a different kind of work. Rebuilding a scorecard means someone has to answer what predicts churn in your business, with evidence, and get three people to agree. Rebuilding segments means re-litigating how the book is cut. Rebuilding Plays means deciding, again, what your team does when an account slips. These are the arguments the original implementation had, and you are having them a second time, usually with different people in the room.
Then validation. A new scorecard nobody has tested is a scorecard nobody trusts, and the only honest test is running it backwards against accounts that already churned. That takes a cycle. Then the parallel run, because cutting over mid-renewal-cycle is how accounts go dark, and most teams keep both systems live for one full cycle to avoid it.
None of that is a data task. It is why three to five months is the honest number for a platform-to-platform move, and why "we will migrate the data" is the wrong frame for the project.
Which timeline you are actually in
The question that decides it is not which tool you are moving to. It is whether you are rebuilding a model on the other side.
If you are, the clock is set by decisions and agreement, not by the export, and no amount of connector quality shortens it. If you are not, because the receiving system scores accounts from connected data rather than from a model you design, the export is most of the work and the timeline collapses to days.
That is the actual reason GainTrace is seven days and a platform migration is months. It is not a better importer. It is that there is nothing to re-decide before the thing is useful.
The trade is real and worth stating plainly: you get a working score in a week, and in exchange you accept a scoring model you did not design. For a team that already has a scorecard they trust and a year of argument invested in it, that is a genuine loss. For a team whose scorecard nobody trusts, which is more common than the category admits, it is the point.
The pass nobody schedules
Whichever route you take, add reconciliation. ChurnZero sends no website on an account, so records arrive with no key to match against customers you already hold in a CRM or a billing system. Somebody joins those up by hand, and it is always slower than it sounds on a book of any size.
Leaving ChurnZero: what actually comes out
One thing decides how hard this is. ChurnZero's REST API is a paid add-on. With it, your data can be read out programmatically. Without it you are exporting one screen at a time from the interface, which returns the current state of a record rather than the trail behind it. Ask your ChurnZero CSM which you have before you plan anything else.
GainTrace reads ChurnZero through that API with an API username and key, and brings over accounts, contacts, owners, notes, meetings, messages, tasks, survey responses, ChurnScore history and contract values. ChurnScore history lands on a separate card in ChurnZero's own scale and is never mixed into a new score, so you keep the record without inheriting a model you cannot see.
Two limits worth knowing up front. ChurnZero sends no website on an account, so records arrive as new rather than merging with customers you already hold elsewhere. And notes arrive without an author, because the API does not record who wrote them.
Nothing is written until you review what moves, and imported records trigger no flows, webhooks or signal detection. GainTrace only ever reads; it never writes to ChurnZero. The permissions, the object-by-object list and the full set of what stays behind are in the ChurnZero migration reference.
If you are still deciding where to go rather than how to get there, our comparison of ChurnZero competitors covers the options.
Want to see what would move from your ChurnZero account? Start GainTrace free.
Free forever on your first 25 companies | No credit card required
Frequently Asked Questions
- How do I migrate from ChurnZero?
- You migrate from ChurnZero through its REST API, which is a paid add-on, using an API username and key. Your ChurnZero admin needs three things in place: the add-on enabled, an API user with the Developer Tools permission, and Bulk Read permissions granted per object. With those set, accounts, contacts, owners, notes, meetings, messages, tasks, survey responses, ChurnScore history and contract values can all be read out programmatically. Without the add-on you are exporting screen by screen from the interface, which returns current records rather than their history.
- How do I export data from ChurnZero?
- There are two routes out of ChurnZero, and only one carries history. The REST API is the complete route: it needs the paid add-on plus per-object Bulk Read permissions, and it returns activity trails, score history and original survey dates. The interface export is available on every account but works one view at a time and returns the current state of a record, not the trail behind it. If history matters, the API is the only option.
- What does ChurnZero’s API not expose?
- ChurnZero's API does not expose Plays or Alerts at all, which is the single biggest gap. Beyond that: ChurnScore factors come through as names and types without the points each carries or its thresholds, segments are listed without their filters, there is no success plan object, note authors and draft notes are not returned, product subscriptions carry no price and no history, and file attachments are unavailable. Journeys can be read but do not translate into another system's automation.
- Does ChurnScore history come out of ChurnZero?
- ChurnScore history does come out, up to about two years at one point per week, as far back as your instance has kept it. Some ChurnZero instances store only the current score for each account, and in that case there is no history to export. What never comes out is the model behind the score. The factors are listed by name and type but not the points each carries or its thresholds, so the scoring itself is always a rebuild rather than a transfer.
- Can I move my ChurnZero Plays to another platform?
- No, ChurnZero Plays cannot be moved to another platform, because the API does not expose Plays or Alerts and there is nothing to read. Journeys can be read but do not map onto another system's automation. Treat your existing Plays as a written specification to rebuild from rather than something to transfer, and budget that rebuild into the project rather than the export.
- Do I lose my activity history when leaving ChurnZero?
- You keep your activity history if you leave through the API, and generally lose it if you leave through the interface. Notes, meetings and messages come out with their original dates, which is the main reason the paid add-on is worth having. Two things do not survive: notes arrive without an author, because the API does not record who wrote them, and draft notes stay behind because they are private to their author.
- How long does a ChurnZero migration take?
- Moving your ChurnZero data into GainTrace takes seven days. Moving it into another customer success platform typically takes three to five months. The export takes days either way. The months go on rebuilding what does not export: scores, segments and Plays all come out without their rules attached, so a full platform means re-deciding the model before it is useful.
- Why do my ChurnZero accounts not match my existing records?
- ChurnZero accounts do not match existing records because ChurnZero sends no website on an account, so there is no domain to match against. Records arrive as new rather than merging with customers you already hold in another system. If you are consolidating rather than starting clean, budget for a reconciliation pass and decide in advance which system is the source of truth for company names.
- Will exporting from ChurnZero slow down our other tools?
- Yes, it can. ChurnZero applies a single per-minute API limit to your whole instance, shared by every tool reading through the REST API, including reporting connections such as Power BI. A large export competes with those connections for the same budget, so your export can be slowed by them and theirs can be slowed by you. Tell whoever owns your reporting integrations before you begin.
