---
title: "Zendesk Legacy Custom Objects Removal: Migration Guide"
slug: zendesk-legacy-custom-objects-removal-migration-guide
date: 2026-11-09
author: Abdul Aleem
categories: [Zendesk, Migration Guide, Help Desk]
excerpt: "Zendesk removed legacy custom objects on July 27, 2026. No automated migration exists. Here's how to extract, transform, and load your data into the new framework."
tldr: "Zendesk legacy custom objects were fully removed July 27, 2026. Migration is a manual ETL process — export via the legacy API or CSV tool, map JSON Schema types to new fields, and reload via the API or data importer."
canonical: https://clonepartner.com/blog/zendesk-legacy-custom-objects-removal-migration-guide
---

# Zendesk Legacy Custom Objects Removal: Migration Guide


# Zendesk Legacy Custom Objects Removal: Migration Guide

Zendesk fully removed legacy custom objects — the legacy APIs, Admin Center UI, and all record data — on July 27, 2026 ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/9156194392730)). There is no automated migration path ([developer.zendesk.com](https://developer.zendesk.com/documentation/custom-data/custom-objects/migrating/migrating-legacy-custom-objects/)). If you're still running legacy custom objects on an extension, you need to extract your data, rebuild the schema in the new custom objects framework, and reload records through the API or the data importer. This guide covers the exact timeline, the data model differences, the schema mapping, the edge cases that trip up most teams, and the validation steps to confirm nothing was lost.

For pre-migration planning across all Zendesk data types, see the [Zendesk Migration Checklist](https://clonepartner.com/blog/blog/zendesk-migration-checklist).

## What are Zendesk legacy custom objects?

**Zendesk legacy custom objects** (also called "Sunshine Custom Objects") are the original API-driven framework for defining custom data types inside Zendesk. They use JSON Schema to define object types with typed properties, and a separate relationship system to link records to each other or to standard Zendesk objects like tickets and users. The legacy API lives at `/api/sunshine/objects/*`.

Zendesk's replacement custom objects framework is a native feature with Admin Center management, lookup fields, triggers support, and a built-in record viewer on tickets. Legacy custom objects stayed available only to accounts that enabled them before September 2023 ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/4408834725402)). The new API lives at `/api/v2/custom_objects/*`.

Because the underlying architecture changed completely, a direct 1:1 field copy is rarely possible without intermediate transformation. The migration is an extract, transform, and load (ETL) problem — not an upgrade.

## What is the removal timeline?

The removal was announced on July 7, 2025, and executed in two phases: Phase 1 took effect January 15, 2026, and Phase 2 took effect July 27, 2026 ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/9156194392730)).

| Phase | Date | What changed |
|---|---|---|
| Phase 1 | January 15, 2026 | Creating new custom objects or relationships using the legacy version was no longer allowed. New records could still be added to existing legacy objects. |
| Phase 2 | July 27, 2026 | Zendesk fully removed legacy custom objects — the legacy APIs, admin interface, and all legacy custom object records are no longer supported or accessible. |

Zendesk's removal announcement included a request form for a one-time extension. Zendesk has not published an extension end date that applies to every account. If you're unsure whether your account has an extension, or when it ends, check with your Zendesk account representative.

> [!WARNING]
> Do not assume the extension is indefinite. Once it expires, the same full removal applies: APIs, UI, and record data are gone. If your account is operating under an extension, extracting data before your extension ends is a strict engineering priority.

## What exactly was removed?

The removal includes the legacy APIs, admin interface, and object records created using the previous custom objects framework. In practical terms:

- **Legacy API endpoints** (`/api/sunshine/objects/*`) return errors
- **Legacy objects sidebar** in Admin Center is gone
- **All legacy object records and relationship records** are deleted — your legacy object types, relationships, and record data are purged
- Any **third-party integrations** that call the legacy API will break
- Any **custom Zendesk apps** that render legacy object data on tickets will stop working

This is a data-destructive event. If you haven't exported your records, they are unrecoverable after removal.

## How do legacy and new custom objects differ?

The two frameworks share a purpose — extending the Zendesk data model — but differ in architecture, API surface, and constraints.

| Aspect | Legacy custom objects | New custom objects |
|---|---|---|
| API namespace | `/api/sunshine/objects/*` | `/api/v2/custom_objects/*` |
| Schema definition | JSON Schema (`properties`, `type`, `enum`) | Custom object fields (form fields: text, dropdown, checkbox, etc.) |
| Relationships | Separate relationship types and relationship records | Lookup fields on objects — native, first-class references |
| Admin UI | Separate "Legacy objects" section | Integrated into Admin Center under Custom objects |
| Trigger support | None | Native to Zendesk features including triggers |
| Record viewer | Required a custom sidebar app | Built-in related records panel on tickets |
| Plan limits (objects) | 100,000–25,000,000 records depending on plan | 3 objects (Suite Team) up to 50 objects (Suite Enterprise/Enterprise Plus), each supporting a maximum of 100 fields |
| Record hard cap | Plan-dependent | 50 million custom object records |
| Record size | No documented per-record limit | 32 KB maximum per record |
| Idempotent load support | No native mechanism | `external_id` field on every record enables upsert behavior |

The biggest architectural shift is relationships. Legacy custom objects used a separate relationship type and relationship record system. New custom objects use **lookup fields** — a field on one object that references a record on another object or a standard Zendesk entity (ticket, user, organization). This is simpler but has a hard constraint: Suite Team and Suite Growth plans can define a maximum of 5 lookup relationship fields per custom object; Suite Professional and above can configure up to 10 per custom object. The object, field, record, and size limits in the table above come from Zendesk's custom objects documentation ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/5914453843994)).

**Plan limit escalation:** If your legacy setup exceeds new plan limits — more than 50 object types, more than 10 lookup fields per object, or more than 100 fields per object — you have three options: (1) consolidate object types that share similar schemas, (2) upgrade your Zendesk plan tier, or (3) store excess lookup references as text fields containing the target record ID and handle resolution in your application layer.

## How to check if your account uses legacy custom objects

In Admin Center, click **Objects and rules > Custom Objects** and check for "Legacy objects" in the sidebar. If you see a "Legacy objects" entry, your account has them. If legacy custom objects are present but not actively used, no further action is needed ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/9418212259098)).

To gauge scope, use the legacy Limits API to count records:

```bash
curl https://{subdomain}.zendesk.com/api/sunshine/limits \
  -H "Authorization: Bearer {token}"
```

Identify any installed apps or integrations that rely on your legacy objects. This includes Zendesk Apps Framework apps that read or write legacy object data, middleware (Workato, Zapier, Tray.io), and internal scripts. Every dependency that touches the legacy API must be updated or replaced.

**Authentication note:** Legacy Sunshine APIs accepted OAuth tokens and Basic Auth (email/token). The new `/api/v2/custom_objects/*` endpoints use the same authentication mechanisms, but any scripts that hardcoded the legacy base URL (`/api/sunshine/`) will fail regardless of credential validity. Update the base URL first, then verify auth headers still work.

## Step-by-step migration process

There is no automated way to migrate your legacy custom objects to the new custom objects. Zendesk explicitly states this — no migration wizard, no one-click upgrade path ([developer.zendesk.com](https://developer.zendesk.com/documentation/custom-data/custom-objects/migrating/migrating-legacy-custom-objects/)). The data migration is an extract, transform, and load (ETL) process.

### Step 0: Test in a Zendesk sandbox first

Before touching your production account, replicate the migration in a Zendesk sandbox environment. Create the new custom object schema, load a representative sample of records (at minimum 1% of total volume or 500 records, whichever is larger), and validate field values, lookup field links, and record counts. Only after sandbox validation passes should you execute against production. This step is not optional — schema errors discovered mid-production load require a full rollback and re-run.

### Step 1: Export legacy object types and schemas

Before you can migrate records, you need the shape of the data. Pull your legacy object type definitions including their JSON Schema:

```bash
curl https://{subdomain}.zendesk.com/api/sunshine/objects/types \
  -H "Authorization: Bearer {token}"
```

This endpoint returns every legacy schema definition — property names, data types (string, integer, boolean), enums, and patterns. Document every object type key, its schema properties, and the relationship types that reference it. This output is your mapping source of truth.

Run a JSON Schema diff between your documented schema and your actual extracted records to catch schema drift — fields that exist in records but were never formally defined (or vice versa). Tools such as `ajv` (Node.js) or `jsonschema` (Python) can validate a sample of records against the declared schema before you build the new field definitions.

### Step 2: Export legacy records and relationships

Use the custom object data export tool to download your legacy custom object records and legacy relationship records from Admin Center as CSV files packaged in a ZIP archive. Navigate to **Admin Center > Objects and rules > Custom objects > Objects**, then click **Export Tool** in the banner. Each export is a ZIP file, and each CSV inside holds up to 20,000 records ([developer.zendesk.com](https://developer.zendesk.com/documentation/custom-data/custom-objects/migrating/exporting-legacy-custom-objects-tool/)).

Alternatively, extract records programmatically using cursor-based pagination:

```bash
curl "https://{subdomain}.zendesk.com/api/sunshine/objects/records?type={object_type_key}&per_page=1000" \
  -H "Authorization: Bearer {token}"
```

The `per_page` parameter accepts 1 to 1,000 ([developer.zendesk.com](https://developer.zendesk.com/api-reference/custom-data/custom-objects-api/resources/)). Follow the `links.next` URL in each response, paginate through all records, and store them locally — either in a staging database or a series of JSON files. Do the same for relationship records. Design your extraction script to handle API rate limits gracefully, intercepting `429 Too Many Requests` responses and respecting the `Retry-After` header.

**Avoiding a delta pass:** Use the full export (pagination above) for the migration. Rather than syncing changes made after the export, set the legacy objects to read-only before you export (see the tip below), so nothing changes between export and cutover. If you later run incremental exports on the new custom objects, note that [Zendesk is ending incremental API access for third parties](https://clonepartner.com/blog/blog/zendesk-ending-incremental-apis-for-third-parties-migration-guide), so those calls must use your own first-party credentials.

Do not pipe data directly from the legacy API to the new API in a single script execution. Decoupling extraction from loading protects you against network timeouts and lets you validate the data locally before writing to the new architecture.

> [!TIP]
> Disable write access to legacy custom objects before exporting. Zendesk's migration guide points to the Legacy Custom Objects Permissions APIs for this ([developer.zendesk.com](https://developer.zendesk.com/documentation/custom-data/custom-objects/migrating/migrating-legacy-custom-objects/)). This prevents data drift during migration.

### Step 3: Create new custom objects and fields

For each legacy object type, create a corresponding new custom object:

```bash
curl https://{subdomain}.zendesk.com/api/v2/custom_objects \
  -d '{
    "custom_object": {
      "key": "vehicle",
      "title": "Vehicle",
      "title_pluralized": "Vehicles"
    }
  }' \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer {token}" -X POST
```

Zendesk's guide suggests reusing the legacy object type's key as is. Settle naming now, because the `key` can be set only on create and cannot be updated later ([developer.zendesk.com](https://developer.zendesk.com/api-reference/custom-data/custom-objects/custom_objects/)).

Then create fields for each schema property. This is where the type mapping matters:

#### Schema property type mapping reference

| Legacy JSON Schema type | New custom object field type | Notes |
|---|---|---|
| `integer` | `integer` | Direct mapping |
| `number` | `decimal` | Do not use `integer` — precision loss for floats |
| `boolean` | `checkbox` | |
| `string` (plain) | `text` | Use `textarea` for long strings; use `date` for ISO date strings |
| `string` + `pattern` | `regexp` | Carry the `regexp_for_validation` value from legacy schema |
| `string` + `enum` | `dropdown` | Convert enum values to `custom_field_options` array |
| `array` | `text` | Serialize as JSON string; no native array type in new framework |
| Multiple types (`["string", "integer"]`) | `text` | Cast all values to strings; document the coercion |

This mapping follows Zendesk's schema migration guide ([developer.zendesk.com](https://developer.zendesk.com/documentation/custom-data/custom-objects/migrating/migrating-legacy-custom-object-schemas/)). If the schema of a legacy custom object has a `name` or `external_id` property, skip migrating these as custom fields — instead use the standard fields (`standard::name` and `standard::external_id`) that are automatically created on every new custom object.

Create each field via the API:

```bash
curl https://{subdomain}.zendesk.com/api/v2/custom_objects/{custom_object_key}/fields \
  -d '{
    "custom_object_field": {
      "key": "license_plate",
      "title": "License Plate",
      "type": "text"
    }
  }' \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer {token}" -X POST
```

### Step 4: Transform and load records using `external_id` for idempotency

Transform your exported CSV or JSON data to match the new schema, then load records. The critical technique here is setting `external_id` on every record you create.

**Use `external_id` as the legacy record ID.** The new custom objects API supports an `external_id` field on every record. Zendesk's guide suggests copying the legacy record's `external_id` if present, or its `id`, into this field ([developer.zendesk.com](https://developer.zendesk.com/documentation/custom-data/custom-objects/migrating/migrating-legacy-custom-objects/)). A plain POST create is not an upsert. To make re-runs safe, load through an upsert path instead:

- `PATCH /api/v2/custom_objects/{custom_object_key}/records?external_id={id}` updates the record with that external ID, or creates it if none exists.
- `POST /api/v2/custom_objects/{custom_object_key}/jobs` with the `create_or_update_by_external_id` action does the same for up to 100 records per request ([developer.zendesk.com](https://developer.zendesk.com/api-reference/custom-data/custom-objects/custom_object_records/)).

Without an upsert path, any interrupted load produces duplicate records that must be manually identified and deleted before retrying.

**API path** (best for automation and large volumes). A single-record create looks like this:

```bash
curl https://{subdomain}.zendesk.com/api/v2/custom_objects/{custom_object_key}/records \
  -d '{
    "custom_object_record": {
      "name": "SN-987654321",
      "external_id": "legacy-record-id-456",
      "custom_object_fields": {
        "serial_number": "SN-987654321",
        "expiration_date": "2027-12-31"
      }
    }
  }' \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer {token}" -X POST
```

Store the response from Zendesk, specifically the new `id` assigned to the created record. You must maintain a mapping table correlating the legacy record ID to the new record ID — `{legacy_record_id → new_record_id}` — for every object type. This mapping table is mandatory for rebuilding relationships in the next phase.

**Rollback procedure:** If you discover schema errors mid-load (wrong field types, truncated values, encoding problems), the correct recovery path is:
1. Stop the load script immediately.
2. Use the new API to delete all records created in the failed run. If you used `external_id`, you can query records by `external_id` to identify exactly which records were created in the bad batch.
3. Fix the schema or transformation logic.
4. Re-run the load through the upsert path. Because `external_id` values match, it overwrites any partially created records rather than duplicating them.

**Data importer path** (best for smaller datasets): You can use the data importer to import a CSV file that creates new custom object records or updates existing records. Navigate to **Admin Center > Objects and rules > Tools > Data importer**, select your custom object, and upload the transformed CSV. The import CSV file cannot exceed 1 GB in size, and Zendesk recommends a maximum of 500,000 rows ([support.zendesk.com](https://support.zendesk.com/hc/en-us/articles/6100391508250)). Include an `external_id` column in your CSV even when using the importer. The importer needs it to update records, so a "Create and update" re-run can fix a bad batch without duplicates.

### Step 5: Migrate relationship records as lookup fields

This is where most teams get stuck. Legacy relationships were separate records linking two objects by ID. New custom objects use **lookup fields** — a field on one object whose value is the ID of a record on another object.

The sequence matters: **import child objects first**, retrieve their new record IDs, then populate the parent object's lookup field with those IDs.

Linking objects with lookup fields is done via the ID of the new object record in Zendesk — you cannot use legacy object IDs directly. Import child objects first to obtain their new IDs, then reference those IDs when creating parent object records.

Use the mapping table generated during Step 4 when transforming parent records. If a legacy custom object was linked to Ticket #1234, parse that legacy relationship, find the new ID of the custom object using the mapping table, and update the ticket's lookup field with that new record ID.

Failure to maintain referential integrity during this phase results in orphaned records and broken UI components within the Zendesk agent workspace.

> [!CAUTION]
> **Closed ticket relationships cannot be restored.** Tickets can't be modified after they've been closed or archived, so their lookup fields can't be set ([developer.zendesk.com](https://developer.zendesk.com/documentation/custom-data/custom-objects/migrating/migrating-legacy-custom-objects/)). If you had relationships between legacy objects and closed tickets, you cannot migrate these to actual lookup field relationships. The workaround is to store the original ticket ID as a text field on the new custom object record so the link is preserved as a queryable reference, even if it isn't a live lookup. Document every affected record so support teams know the reference exists.

## API rate limits that affect the migration

Both the export and import phases are rate-limited, and for most accounts the import side is the bottleneck.

**Legacy API (export side):** Legacy Custom Objects API requests are limited to 250–1,000 per minute depending on plan ([developer.zendesk.com](https://developer.zendesk.com/api-reference/introduction/rate-limits/)).

**New API (import side)** ([developer.zendesk.com](https://developer.zendesk.com/api-reference/introduction/rate-limits/)):

| Plan | Requests per minute |
|---|---|
| Suite Team | 200 |
| Suite Growth | 400 |
| Suite Professional | 400 |
| Suite Enterprise | 700 |
| Suite Enterprise Plus / High Volume add-on | 2,500 |

**Incremental export endpoint:** The incremental export for new custom object records (`GET /api/v2/incremental/custom_objects/{custom_object_key}/cursor`) is limited to 10 requests per minute ([developer.zendesk.com](https://developer.zendesk.com/api-reference/custom-data/custom-objects/custom_object_records/)). It reads the new framework, not legacy records, so it is useful for post-load checks rather than extraction.

**Load time estimates by plan and volume:**

| Record count | Suite Professional (400 req/min) | Suite Enterprise (700 req/min) |
|---|---|---|
| 10,000 | ~25 min | ~15 min |
| 50,000 | ~2.1 hours | ~1.2 hours |
| 500,000 | ~20.8 hours | ~11.9 hours |

These estimates assume one API call per record with no retries or throttling. Retries, error handling, and network latency add time. The bulk jobs endpoint handles up to 100 records per request, which cuts the call count sharply. Build retry logic with exponential backoff (starting at 1 second, doubling to a maximum of 60 seconds) and always respect `Retry-After` headers on 429 responses.

## Validating data integrity after loading

Do not consider the migration complete until you have run multi-stage validation. Four checks are non-negotiable:

1. **Record-count parity:** The total number of legacy records extracted must exactly match the number of records successfully created in the new schema. Query both counts programmatically — do not rely on UI counts. Any delta means records were dropped or duplicated.
2. **Field-level spot check:** Randomly sample at least 5% of the migrated records and compare field values against the legacy source payload. This catches data truncation (values exceeding field-type limits), type coercion errors (integer overflow, float precision), and encoding issues (non-UTF-8 characters) that record counts alone will not surface.
3. **Referential integrity checks:** Query the new relationship endpoints (lookup field values) to confirm that every linked ticket, user, or child object in the legacy system retains its link in the new system. Pay special attention to the closed-ticket edge case: log every instance where a legacy relationship targeted a closed ticket and store those ticket IDs in the fallback text field.
4. **`external_id` uniqueness check:** Query all records in the new object and confirm no two records share the same `external_id`. Duplicate `external_id` values indicate a logic error in the upsert path and will cause silent data integrity problems in future delta syncs.

## What if you missed the July 27 deadline?

If the removal date has passed and you didn't export your data, your options depend on whether you requested the extension.

- **If you filed for the extension:** Your legacy objects may still be accessible. Export immediately and begin migration. The extension is a one-time grant, and Zendesk has not committed to further extensions.
- **If you didn't file and have no extension:** Legacy records are gone. Check whether you have backups in middleware logs (Workato, Tray.io), data warehouse extracts, or third-party backup services. If any integration was reading legacy object data on a schedule, those cached copies may be your only recovery source.

## How long does a Zendesk custom object migration take?

Migration duration is a function of three variables: record volume, API rate limit (plan tier), and schema complexity (number of object types, number of cross-object relationships requiring ID remapping).

**Load time derivation:** At 400 req/min (Professional plan), 50,000 records require a minimum of 125 minutes of sustained API calls, assuming single-record POST requests. The bulk jobs endpoint reduces this, and retries add to it. Schema complexity — particularly multi-hop relationship remapping — adds elapsed time independently of API throughput because it requires sequential dependency resolution (child before parent).

Most migrations are completed within 1–5 business days, depending on data volume, complexity, and API rate limits. Small datasets (under 10,000 records) can finish in under 24 hours.

These figures describe the data migration ClonePartner performs. Rebuilding dependent apps, triggers, workflows, and agent training is a separate project that your team runs on its own timeline. Plan for a parallel-run period where both old and new systems are readable before fully cutting over.

## Securing data during the transition

Migrating custom objects often involves handling personally identifiable information (PII) or sensitive customer data. Any migration process that extracts records to an intermediate staging environment should enforce:

- **Encryption at rest** (AES-256 minimum) for staging databases and local JSON/CSV exports
- **Encryption in transit** (TLS 1.2+) for all API calls
- **Access controls** limiting staging data access to named engineers involved in the migration
- **Automatic purge** of staging data within 30 days of project completion
- **DPA/BAA execution** before handling data subject to GDPR, CCPA, or HIPAA

ClonePartner operates under SOC 2 Type II and ISO 27001 certifications (independently audited) and follows the above controls on every migration project.

## When to bring in help

If you have a handful of simple object types with a few hundred records, the Zendesk developer docs and the data importer will get you there. The complexity scales quickly with: multiple object types with cross-references, schema properties requiring type conversion, thousands of relationship records requiring ID remapping, closed-ticket edge cases, and dependent apps that must be rebuilt in parallel.

For a broader Zendesk project, see our guide to [Salesforce Service Cloud to Zendesk migrations](https://clonepartner.com/blog/blog/salesforce-service-cloud-to-zendesk-migration-technical-guide). Our process follows a strict sequence: **Connect accounts → migration checklist → sample migration → full migration → delta sync.** We provide unlimited sample migrations until the data is right.

We offer one fixed price per project, starting at $500. No hourly billing, no hidden fees, no change orders, no per-record metering. Pricing is driven by data volume, complexity, and the platforms involved.

For related migration guides, see:
- [How to Migrate Custom Objects and Associations Between CRMs](https://clonepartner.com/blog/blog/how-to-migrate-custom-objects-and-associations-between-crms)
- [Kustomer to Zendesk Migration: The CTO's Technical Guide](https://clonepartner.com/blog/blog/kustomer-to-zendesk-migration-the-ctos-technical-guide)

> Need legacy custom object data migrated to Zendesk's new framework? Book a free 30-minute scoping call with a migration engineer. One fixed price, no hourly billing.
>
> [Talk to us](https://clonepartner.com/talk-to-us?duration=30&utm_source=blog&utm_medium=button&utm_campaign=demo_bookings&utm_content=cta_click&utm_term=demo_button_click)

## Frequently asked questions

### When did Zendesk remove legacy custom objects?

Zendesk removed legacy custom objects in two phases. Phase 1 (January 15, 2026) blocked creation of new legacy objects. Phase 2 (July 27, 2026) fully removed the legacy APIs, admin interface, and all record data. Zendesk's announcement offered a request form for a one-time extension, but Zendesk has not published an extension end date that applies to every account.

### Is there an automated migration from legacy to new Zendesk custom objects?

No. Zendesk's own documentation states there is no automated migration path. You need to export legacy data via the CSV export tool or legacy API, transform it to match the new custom object schema, and load it through the new Custom Objects API or the Admin Center data importer.

### How do legacy custom object schema types map to new custom object fields?

Integer maps to integer, number maps to decimal, boolean maps to checkbox, plain string maps to text, string with enum maps to dropdown, string with pattern maps to regexp, and array maps to text (serialized as a JSON string). Properties with multiple types also map to text.

### Can I migrate legacy object relationships to closed tickets?

No. Zendesk does not allow lookup fields to be updated on closed tickets. If you had relationships between legacy objects and closed tickets, a workaround is to store the original ticket ID as a text field on the new custom object record rather than a live lookup.

### What are the Zendesk API rate limits for custom object record imports?

Rate limits depend on your plan: 200 requests per minute on Suite Team, 400 on Growth and Professional, 700 on Enterprise, and 2,500 on Enterprise Plus or with the High Volume API add-on. The incremental custom object record export endpoint is limited to 10 requests per minute.