Deciding to migrate your engineering or support team off Zendesk to a modern stack like Plain, Pylon, or Linear is usually the easy part. The pricing gets too high, the interface feels bloated, and the decision is made.
But then comes the migration sprint, and your data team hits a wall: Getting 5 years of historical data out of Zendesk is a nightmare — and Sunshine Custom Objects are the hardest piece.
Zendesk's official deprecation notice targets July 1, 2026. After that date, the Sunshine Custom Objects API returns 410 Gone and the data is unrecoverable. We cover the technical consequences in detail on our Sunshine export landing page.
This guide explains exactly what Sunshine Custom Objects are, why standard exports miss them, and what a correct extraction produces.
What Are Sunshine Custom Objects, Exactly
Sunshine Custom Objects are Zendesk's mechanism for storing arbitrary business data attached to tickets, users, or organizations. Unlike Custom Fields, which are key/value pairs on existing entities, Custom Objects are independent record types with their own schemas, relationships, and attributes.
Common Custom Object types in production Zendesk instances:
- Hardware asset records, such as serial number, model, purchase date, and warranty status, linked to tickets via
lookuprelationships - License entitlement records, such as license key, seat count, and renewal date, linked to organizations
- Product-specific SLA configurations that override defaults
- B2B account hierarchies that don't fit Zendesk's flat Organization model
These records have foreign key relationships back into ticket and user tables. Lose them, and you lose the relational context that makes your support history useful for compliance, product analytics, and customer health scoring.
The Zendesk Data Ransom: Why Standard ETLs Fail at Custom Objects
You quickly realize that your historical ticket threads, internal notes, and deeply nested custom assets are held hostage by an archaic API. Here is the reality of the "Data Ransom" phase — why standard ETL tools fail silently, and why so many companies end up paying a "forever tax" to Zendesk long after they've migrated.
The Flat CSV Trap
If you rely on Zendesk's native data export, you get a massive, flattened CSV. For a serious B2B company, this is useless — and for Custom Objects, it's worse than useless: the native export doesn't include Custom Objects at all.
Zendesk stores critical context in nested JSON blobs. In a native CSV export, via.channel data is flattened, meaning you completely lose the context of whether a specific comment was a customer reply or a private internal staff note. If your ML team tries to use this flat data to train an AI support agent or a RAG pipeline, the model will hallucinate internal notes as customer-facing answers.
Why Fivetran and Airbyte Fail Silently
When the native export fails, most data teams turn to their standard ETL pipelines. They plug Fivetran into the Zendesk API and expect it to magically sync to their Postgres or Snowflake warehouse.
Here is the fatal flaw: Standard ETL tools are built for continuous, Monthly-Active-Row (MAR) syncing, not surgical, one-off historical migrations. More importantly, they frequently fail on Sunshine Custom Objects.
If you use Zendesk to track software licenses, hardware assets, or custom subscription entitlements, that data lives in Sunshine. Because Custom Object schemas are defined per-instance, there is no canonical schema. Because Zendesk nests attributes inconsistently, sometimes under .attributes and sometimes under .custom_object_fields, tools like Fivetran often skip them entirely. No error. No warning. You only catch it two weeks later when an engineer realizes the row counts don't match the API.
What the Sunshine API Actually Returns
Here's what a Custom Object record looks like when you query the Sunshine API directly:
{
"data": {
"type": "hardware_asset",
"id": "01HC8X9Y3Z2K5M7N9P1Q3R5T7V",
"attributes": {
"serial_number": "MX4-882193",
"model": "MacBook Pro 16-inch (2024)",
"purchase_date": "2024-09-15",
"warranty_expires_at": "2027-09-15",
"current_user_id": 28471
},
"relationships": {
"assigned_ticket": {
"data": { "type": "ticket", "id": "48211" }
}
},
"created_at": "2024-09-16T14:22:01Z",
"updated_at": "2025-11-03T09:14:38Z"
}
}
Two things make this hard to extract correctly:
-
The schema is per-instance. The
attributeskeys are whatever the Zendesk admin chose when creating the object type. There is no documented schema to map against. -
Relationships are bidirectional and not always reciprocal. A
hardware_assetmay reference aticket, but the ticket doesn't directly reference the asset. Reconstructing the full relational graph requires walking both directions.
The "DIY Python Script" Illusion
Once the ETL tool fails, the engineering team decides to "just script it."
Zendesk's API uses incompatible pagination strategies across different data types, and they don't compose cleanly in a single extraction pass.
Furthermore, pulling heavy historical ticket events triggers Zendesk's aggressive rate limits. Your script crashes. Fixing it properly requires engineering infrastructure that compounds in complexity with every edge case you discover. We detail the quirks of the Zendesk Incremental Export API in a separate deep dive.
What was supposed to be a "quick afternoon export" turns into a two-week engineering sprint.
The Abandoned-Seat Compromise
Because the engineering cost of extracting the data is so high, most CTOs make a rational, but painful, compromise.
They migrate to their new helpdesk, but they leave one "Read-Only Admin Seat" active on Zendesk. They pay Zendesk $100+ a month, indefinitely, just so their compliance and legal teams have a place to look up 4-year-old ticket histories or hardware assets.
This is the abandoned-seat billing trap. It is a forever tax on your infrastructure — and after July 1, 2026, the Sunshine data behind that seat is gone anyway.
What a Correct Extraction Produces
The target schema for a Sunshine Custom Objects extraction should preserve both the per-type attributes and the relationship graph:
CREATE TABLE custom_object_records (
id TEXT PRIMARY KEY,
object_type TEXT NOT NULL,
external_id TEXT,
created_at TIMESTAMPTZ NOT NULL,
updated_at TIMESTAMPTZ NOT NULL,
attributes JSONB NOT NULL
);
CREATE TABLE custom_object_relationships (
id TEXT PRIMARY KEY,
source_type TEXT NOT NULL,
source_id TEXT NOT NULL,
target_type TEXT NOT NULL,
target_id BIGINT NOT NULL
);
CREATE INDEX idx_rel_target ON custom_object_relationships(target_type, target_id);
CREATE INDEX idx_rel_source ON custom_object_relationships(source_type, source_id);
With this shape, you can join Custom Objects back to tickets and users in standard SQL, query them with JSONB operators, and preserve the bidirectional relationship graph that Zendesk's native export discards.
The Escape Hatch: Stateless, LLM-Powered Extraction
Evicta is here to change this mathematical equation. If extracting the data costs less than a two-week engineering sprint and less than a year of paying for an abandoned seat, the decision to do a clean exit becomes a no-brainer.
Evicta is a stateless, zero-persistence extraction engine built specifically for this one job.
- Dynamic Governors: Natively handles Zendesk's 429 rate limits and dual-pagination automatically.
- LLM Schema Mapping: Reads your unique Sunshine Custom Object schemas and maps them accurately, preserving relational integrity.
- Zero-Persistence: 0 bytes of your PII touch our disks. Data streams directly into an ephemeral, encrypted vault, delivering a perfectly mapped SQL or JSONL archive.
You run it once, drop the resulting JSONL or SQL files into AWS S3 Glacier for compliance, or feed it directly into your AI training pipeline, and you can finally click "Cancel Account" on Zendesk.
No abandoned seats. No forever tax. Your data, unlocked.
If you're actively planning your Sunshine migration, see our Sunshine sunset export landing page for the timeline and the extraction architecture in detail.
Sunshine is one facet of the broader migration extraction problem. We cover the general failure modes in The Helpdesk Migration Trap.
Frequently Asked Questions
What happens to Zendesk Sunshine Custom Objects on July 1, 2026?
After July 1, 2026, Zendesk's Sunshine Custom Objects API returns 410 Gone. All endpoints under /api/sunshine/objects/* stop responding. The data is not migrated automatically to Zendesk's newer Custom Objects platform — any records stored exclusively in legacy Sunshine are permanently inaccessible after the sunset date.
How do I know if I'm using legacy Sunshine vs. the new Custom Objects platform?
Three signals indicate legacy Sunshine usage: (1) your Zendesk admin panel has a "Sunshine" menu item distinct from "Custom Objects", (2) your API integrations call /api/sunshine/objects/... endpoints, (3) you defined custom object types before late 2023. If you're unsure, the Custom Objects discovery endpoint /api/v2/custom_objects lists what your instance has.
Can Fivetran or Airbyte extract Zendesk Sunshine Custom Objects?
Fivetran and standard ETLs often fail or silently skip deeply nested Zendesk Sunshine Custom Objects. The connectors expect fixed schemas, and Sunshine's per-instance schema model breaks that assumption. A purpose-built, LLM-mapped extraction tool is required to parse these nested JSON blobs and preserve the relationship graph.
What does a correct Sunshine extraction preserve?
Three things: (1) the full attributes JSON for each record, preserved as JSONB so it remains queryable, (2) the bidirectional relationship records linking Custom Objects to tickets, users, and organizations, and (3) the per-type schema metadata so you can understand what each field represents months later.
How much does an abandoned Zendesk seat cost over time?
A single read-only Zendesk admin license runs $100 or more per month. Companies that migrate but keep an abandoned seat for compliance access pay $1,200 or more per year — indefinitely — just to look up historical data they already own. And after July 1, 2026, the Sunshine data behind that seat is gone anyway.