---
title: "IBM Control Desk End of Support (2026): Technical Migration Guide"
slug: ibm-control-desk-end-of-support-2026-technical-migration-guide
date: 2026-11-09
author: Raajshekhar Rajan
categories: [Migration Guide, Help Desk]
excerpt: "IBM Control Desk 7.6.1.x loses all support December 31, 2026. Technical guide to migrating tickets, CMDB, assets, and work logs to your next ITSM platform."
tldr: "IBM Control Desk 7.6.1.x loses all support on December 31, 2026. Migrating tickets, CMDB, and assets requires navigating Maximo's relational database via OSLC REST APIs and loading data in strict dependency order."
canonical: https://clonepartner.com/blog/ibm-control-desk-end-of-support-2026-technical-migration-guide
---

# IBM Control Desk End of Support (2026): Technical Migration Guide


# IBM Control Desk End of Support (2026): Technical Migration Guide

IBM Control Desk 7.6.1.x loses all IBM support on **December 31, 2026**, when sustained support, the final stage, ends. Standard support already ended on September 30, 2025 ([ibm.com](https://www.ibm.com/support/pages/node/7269505)). After December 31, 2026: no fixes, no patches, no security updates, no escalation path. If you're still running ICD, you need a migration plan, and you need to understand what "migration" actually means for a Maximo-based ITSM platform where tickets, changes, assets, and CIs all live in a shared relational database with deep cross-references.

This guide covers the end-of-support timeline, the ICD data model and why it makes extraction hard, the realistic target platforms, the extraction approaches that work, and the relationship-mapping problems that break most migrations.

> [!NOTE]
> **Quick answer:** Migrating from IBM Control Desk is a high-complexity data extraction project due to the underlying Maximo relational database structure. Most data migrations complete within 1–5 business days, depending on data volume, complexity, and API rate limits. That timeline describes the data migration ClonePartner performs. Your internal project to rebuild workflows and replatform is a separate effort on your own timeline. With sustained support ending December 31, 2026, start scoping now.

## What is IBM Control Desk?

**IBM Control Desk (ICD)** is an ITIL-compliant IT service management and asset management platform built on IBM's Maximo/Tivoli process automation engine. It manages service requests, incidents, problems, changes, releases, assets, and configuration items in a single relational database. IBM has folded its capabilities into **Maximo IT**, an add-on to the Manage application within IBM Maximo Application Suite (MAS) ([ibm.com](https://www.ibm.com/support/pages/ibm-maximo-application-suite-ibm-maximo-it-81)). IBM formally announced the transition in September 2023 ([ibm.com](https://www.ibm.com/support/pages/node/7269505)). The product is no longer sold, and the clock is running down to the final support cutoff.

## IBM Control Desk end-of-support timeline

The support withdrawal is staged, not sudden ([ibm.com](https://www.ibm.com/support/pages/node/7269505)):

| Milestone | Date |
|---|---|
| End of Marketing (no new sales) | April 19, 2024 |
| End of Standard Support | September 30, 2025 |
| Extended Support (optional, one year) | October 1, 2025 – September 30, 2026 |
| Sustained Support (final stage) | October 1, 2025 – December 31, 2026 |
| **All support ends** | **December 31, 2026** |

IBM's own guidance states that after December 31, 2026, there are no support, maintenance, or escalation options available. Organizations with compliance, security, or availability requirements face compounding risk if they continue running unsupported software. (Note that ICD is not the only legacy platform facing this exact cutoff; [Cherwell also reaches end of life on December 31, 2026](https://clonepartner.com/blog/blog/cherwell-end-of-life-december-2026-data-migration-guide).)

> [!WARNING]
> **Sustained support is not standard support.** IBM's sustained support covers usage questions, known defects, and existing fixes — no new defect fixes and no new security patches ([ibm.com](https://www.ibm.com/support/pages/ibm-sustained-support-offering)). Optional extended support, where bought, covered critical issues only until September 30, 2026. If you haven't started planning, you are already operating on borrowed time.

## What data lives inside IBM Control Desk?

ICD's data model is the Maximo data model. Understanding the underlying table structure is the first step to scoping a migration, because the relationships between these tables are where migrations break.

### Key foreign key relationships across the core tables

The following join structure governs how ICD data is connected. Any migration that does not preserve these relationships produces broken records in the target system:

| Child Table | Join Columns | Parent Table | Notes |
|---|---|---|---|
| `WORKLOG` | `RECORDKEY` + `CLASS` | `TICKET` (`TICKETID` + `CLASS`) | Work logs owned by ticket class |
| `WORKLOG` | `RECORDKEY` + `CLASS` | `WORKORDER` (`WONUM` + `WOCLASS`) | Work logs owned by change/release |
| `COMMLOG` | `OWNERID` + `OWNERTABLE` | `TICKET` or `WORKORDER` | Spans record types via polymorphic join |
| `MULTIASSETLOCCI` | `RECORDKEY` + `RECORDCLASS` | `TICKET` or `WORKORDER` | Links records to assets, locations, CIs |
| `MULTIASSETLOCCI` | `ASSETNUM` + `SITEID` | `ASSET` | Asset side of the join |
| `MULTIASSETLOCCI` | `CINUM` | `CI` | CI side of the join |
| `DOCLINKS` | `OWNERTABLE` + `OWNERID` | `TICKET`, `WORKORDER`, `ASSET`, `CI` | Polymorphic attachment reference |
| `TKSTATUS` | `TICKETID` + `CLASS` | `TICKET` | Status history per ticket |
| `RELATEDRECORD` | `RECORDKEY` + `CLASS` | `TICKET` or `WORKORDER` | Cross-references between record types |
| `CI` | `ASSETNUM` | `ASSET` | Links an authorized CI to the asset it represents |
| `CLASSSTRUCTURE` | `CLASSSTRUCTURE` (self-ref) | `CLASSSTRUCTURE` | Hierarchical taxonomy, parent→child |

This polymorphic join pattern — where `OWNERTABLE` or `CLASS` determines which parent table a row belongs to — is the most common source of migration failures. A query that filters only on `OWNERTABLE='INCIDENT'` will silently drop records owned by related SRs, problems, or changes.

### Version-specific differences

ICD behavior is not homogeneous across releases and fix packs, and many deployments carry local customizations. Two facts matter for migration tooling:

- **ICD 7.6.1.5** is the version IBM requires for the upgrade to Maximo IT ([ibm.com](https://www.ibm.com/support/pages/icd-761-maximo-it-upgrade-faq)).
- **Object Structures decide what the REST API returns.** A record's child data (work logs, `MULTIASSETLOCCI` rows, attachments, `CIRELATION` rows) appears in a response only if the Object Structure you query includes that child object. IBM's own attachment example requires adding `DOCLINKS` as a child before attachments are exposed ([ibm-maximo-dev.github.io](https://ibm-maximo-dev.github.io/maximo-restapi-documentation/attachment/attachment)).

Whatever your release, audit your Object Structures in the Integration Framework before assuming the OSLC API exposes complete relational data.

### Tickets: service requests, incidents, and problems

All three ticket types share a single underlying **TICKET** table, differentiated by its `CLASS` column. The SR, INCIDENT, and PROBLEM applications are database views on that same table. Incidents carry extra hidden fields (`PROBLEMCODE`, `FR1CODE`, `FR2CODE`) for problem/cause/remedy code reporting. Each ticket carries work logs (`WORKLOG`), communication logs (`COMMLOG`), status history (`TKSTATUS`), and attachments (`DOCLINKS`).

This shared-table design means that when you extract tickets, you are querying one table with class filters — but the target platform almost certainly separates these into distinct tables or record types. A native CSV export from ICD only gives you the top-level fields from the `TICKET` table. It drops conversations, inline attachments, status history, and CI relationships. A production-grade migration requires extracting the data relationally.

### Changes, releases, and activities

Changes and releases follow the same pattern but sit on the **WORKORDER** table. `WOCHANGE`, `WORELEASE`, and `WOACTIVITY` are views filtered by work order class (`WOCLASS` = 'CHANGE', 'RELEASE', 'ACTIVITY'). Changes can spawn activities (child work orders), and tickets can be promoted to changes — creating cross-table references between `TICKET` and `WORKORDER` via `ORIGRECORDID` and `ORIGRECORDCLASS` that must be preserved.

### Assets and the CMDB

IBM Control Desk distinguishes between Assets and Configuration Items (CIs). The **ASSET** table tracks physical and logical assets for financial and lifecycle management (purchasing, depreciation, warranties). The **CI** table stores authorized configuration items for operational and configuration management (change control, dependencies, topologies). A CI links to the asset it represents through its `ASSETNUM` column. The separate **ACTCI** table holds actual CIs, which ICD promotes to create authorized CIs ([ibm.com](https://www.ibm.com/docs/en/control-desk/7.6.1?topic=overview-configuration-item-space)). CI-to-CI relationships live in the **CIRELATION** table, which defines upstream/downstream dependencies with the following structure:

| Column | Description |
|---|---|
| `SOURCECI` | Source CI identifier (`CINUM`) |
| `TARGETCI` | Target CI identifier (`CINUM`) |
| `RELATIONNUM` | Identifier of the relationship type between the two CIs |

The `CIRELATION` table is the topology map that change management and impact analysis depend on. Loading CIs without their `CIRELATION` rows produces an asset list, not a CMDB.

The **MULTIASSETLOCCI** table links work orders and tickets to multiple assets, locations, and CIs simultaneously. This is the join table that connects "what happened" (tickets/work orders) to "what it happened to" (assets/CIs), and it is the most commonly broken linkage in an ICD migration.

### Everything else in scope

A complete ICD extraction typically includes:

- **Persons and person groups** (`PERSON`, `PERSONGROUP`) — agents, requesters, assignment groups
- **Locations** (`LOCATIONS`) — with site and organization hierarchy (`SITEID`, `ORGID`)
- **Solutions / knowledge articles** (`SOLUTION`) — linked to tickets via classification
- **SLA records** — tied to tickets and assets via `SLARECORDS`
- **Classifications** (`CLASSSTRUCTURE`) — the hierarchical taxonomy used across tickets, CIs, and assets; self-referential via `PARENT` column
- **Domain values** (`SYNONYMDOMAIN`, `ALNDOMAIN`, `NUMERICDOMAIN`) — custom status codes, priority values, category mappings

### Multi-site and multi-tenancy considerations

Large enterprise ICD deployments run across multiple `SITEID` and `ORGID` combinations. This creates namespace collision risks during migration: assets are keyed by `ASSETNUM` plus `SITEID`, so two different sites can each have an asset numbered "SERVER001" referring to completely different physical assets. Every extracted record must carry its `SITEID` as part of its natural key, and the target platform must either preserve site context as a field or be pre-scoped to a single site's data. If the target platform does not have a site hierarchy equivalent, the migration must decide — before extraction begins — how to namespace records from multiple sites to prevent collisions. Typically this means prefixing legacy IDs with site codes (e.g., `NYC-SERVER001`, `LON-SERVER001`) in a correlation ID field.

## Where are teams migrating from IBM Control Desk?

IBM recommends Maximo IT as the successor, but many enterprise IT teams use this end-of-support event as the forcing function for a broader ITSM platform change.

### Upgrade to IBM Maximo IT (MAS)

IBM describes Maximo IT as a "lift and shift" of ICD 7.6.1.5 into MAS, with all ITIL processes remaining the same ([ibm.com](https://www.ibm.com/support/pages/ibm-maximo-application-suite-ibm-maximo-it-81)). The upgrade preserves your existing database, but it requires you to be on ICD 7.6.1.5, and it does not support moving from one database platform to another during the upgrade. You cannot upgrade directly from ICD to Maximo IT: you must install MAS first, then deploy Maximo Manage with Maximo IT as an add-on ([ibm.com](https://www.ibm.com/support/pages/icd-761-maximo-it-upgrade-faq)). Ask your IBM sales representative about entitlement trade-ups and licensing transitions.

This is a platform upgrade, not a data migration. The data stays in place; the application layer changes around it.

> [!NOTE]
> **Important distinction:** Upgrading ICD to Maximo IT is IBM's supported in-place upgrade path. Migrating ICD data to a different ITSM platform (ServiceNow, Jira Service Management, Freshservice) is a data migration — a fundamentally different project. The rest of this guide focuses on the data migration scenario.

### Migrate to ServiceNow

ServiceNow is the most common destination for ICD shops moving off the IBM stack entirely. ServiceNow's task table hierarchy (`incident`, `problem`, `change_request`, `sc_req_item`) maps conceptually to ICD's ticket and work order classes, but the table structures are completely different. ServiceNow's CMDB (`cmdb_ci` and its class extensions) uses a different relationship model than Maximo's `CI`/`ACTCI`/`CIRELATION` structure. This is a full data model conversion.

For teams evaluating this path, our [BMC Remedy to ServiceNow migration guide](https://clonepartner.com/blog/blog/bmc-remedy-to-servicenow-migration-the-ctos-technical-guide) covers many of the same Maximo-heritage data model challenges.

### Migrate to Jira Service Management, Freshservice, or another platform

Mid-market teams that do not need ServiceNow's enterprise depth are landing on Jira Service Management or Freshservice. These platforms have simpler data models, which makes field mapping more straightforward — but it means your ICD CMDB complexity will need to be flattened or restructured. (If you are evaluating this trade-off, our guide on [migrating from Jira Service Management to ServiceNow](https://clonepartner.com/blog/blog/migrate-from-jira-service-management-to-servicenow-technical-guide) details the specific differences between JSM's schema-free Assets and ServiceNow's CSDM.) JSM's Assets schema (formerly Insight) supports typed object relationships, but does not have native equivalents for all Maximo `CIRELATION` relationship types. Freshservice's CMDB similarly supports basic CI relationships but lacks the relationship-type taxonomy depth that Maximo provides.

## How to extract data from IBM Control Desk

ICD offers three extraction paths. Which one you use depends on whether your deployment is on-premises or SaaS, and how much data you're moving.

### OSLC / REST API (preferred for automation)

The Maximo Integration Framework exposes OSLC-compliant REST endpoints at `/maximo/oslc/os/{object_structure}`. By querying an Object Structure that includes the child objects you need, the API returns the parent ticket and its associated child records (like work logs) in a structured JSON payload. You can use `oslc.select` for field projection, `oslc.where` for filtering, and `oslc.pageSize` for pagination. Authentication is via API key, which IBM recommends sending in the `apikey` header rather than as a query parameter ([ibm-maximo-dev.github.io](https://ibm-maximo-dev.github.io/maximo-restapi-documentation/authentication/apikey)).

A production-grade extraction call for incidents with child work logs. Here `{incident_os}` stands for an Object Structure over incident tickets that includes `WORKLOG` and `MULTIASSETLOCCI` as children. Check the Object Structures application for one that does, or create it:

```http
GET /maximo/oslc/os/{incident_os}?oslc.where=class="INCIDENT"
  &oslc.select=ticketid,description,status,reportdate,affectedperson,
               worklog{description,logtype,clientviewable,createdate,createby},
               multiassetlocci{assetnum,cinum,location,siteid}
  &oslc.pageSize=100
  &stablepaging=1
  &lean=1
Headers: apikey: <your-api-key>
         Content-Type: application/json
```

Stable paging embeds a stable ID in each `nextPage` link, so the result set does not shift while you page through it ([ibm-maximo-dev.github.io](https://ibm-maximo-dev.github.io/maximo-restapi-documentation/query/sort_and_paging)). Without it, records added or modified during extraction shift page boundaries and cause duplicates or gaps. The stored set expires after five minutes of inactivity, so do not pause mid-run. The `lean=1` parameter strips OSLC metadata from the response, reducing payload size for large extractions.

**Rate limits and page sizes:** The system property `mxe.oslc.maxpagesize` caps the page size, and a request that asks for more fails with an error ([ibm-maximo-dev.github.io](https://ibm-maximo-dev.github.io/maximo-restapi-documentation/query/sort_and_paging)). Check its value on your instance before you choose a page size. For extractions above 100,000 records at a page size of 100, expect multi-hour runs. Build retry logic with exponential backoff into your extraction scripts.

Because IBM Control Desk is often hosted on-premises or in private clouds, extraction speed is directly bottlenecked by the infrastructure's bandwidth and the database's ability to serialize large JSON payloads.

### Direct database queries (on-premises only)

For on-premises ICD deployments, SQL queries against the Maximo database (DB2, Oracle, or SQL Server) are the fastest extraction method. You can export the `TICKET`, `WORKORDER`, `ASSET`, `CI`, `CIRELATION`, `MULTIASSETLOCCI`, and relationship tables directly, preserving foreign key references. This bypasses API rate limits entirely.

The trade-offs are real: you need DBA access, you are working with the raw schema (including Maximo's internal columns), and you must handle the view-to-table mapping yourself. Querying the database directly bypasses the Maximo Business Object (MBO) logic, meaning calculated fields, localized strings, and virtual attributes are absent from the results. Extracting attachments directly from the database requires resolving file system paths stored in `DOCLINKS` — see the attachment section below for the resolution logic.

Direct SQL works well for bulk extraction of structured record data. For attachments and computed fields, the OSLC API is more reliable.

### CSV/XML exports (last resort)

Maximo's built-in reporting and export tools can produce CSV or XML dumps, but they lose relational context. A CSV export of incidents will not include inline work logs, will not preserve CI linkages, and will not carry attachment binary data. CSV is useful for record-count validation checks only — never as the primary extraction method for a production migration. Extraction preference order: API (OSLC) > direct SQL > JSON export > CSV.

### Attachment extraction: resolving DOCLINKS

Maximo links each attachment to its owner record through the `DOCLINKS` table, and each `DOCLINKS` row points to a `DOCINFO` row that describes the document. `DOCINFO` holds the `URLTYPE` and the `URLNAME`. The common values are:

| `URLTYPE` | Meaning | Resolution method |
|---|---|---|
| `FILE` | File stored on the Maximo document library file share | Read the server path in `DOCINFO.URLNAME`; the `mxe.doclink.path01` system property maps that path prefix to a web URL |
| `URL` / `WWW` | External URL reference | Retrieve directly from `URLNAME` |

The URL type is a synonym domain, so your installation may use different internal values. Query the distinct `URLTYPE` values before you write resolution logic ([ibm-maximo-dev.github.io](https://ibm-maximo-dev.github.io/maximo-restapi-documentation/attachment/attachment)).

For `FILE` type attachments, the stored path is a path on the document library share, not a downloadable URL. If the Maximo document library is on a file server not accessible from the extraction host, the files cannot be retrieved via direct path resolution — you need file system access to the document library separately from database access. This is the most common production failure point for attachment migration in ICD environments.

The REST API can list and download attachments through the `doclinks` child of a record, once `DOCLINKS` is added as a child of the Object Structure ([ibm-maximo-dev.github.io](https://ibm-maximo-dev.github.io/maximo-restapi-documentation/attachment/attachment)):

```http
GET /maximo/oslc/os/{object_structure}/{rest_id}/doclinks?lean=1
Headers: apikey: <your-api-key>
```

`{rest_id}` is the resource ID from the record's `href`. The response lists each attachment's metadata. A follow-up `GET .../doclinks/{id}` request retrieves the file content.

## What breaks during an IBM Control Desk migration?

These are the failure modes that appear most consistently across ICD migrations.

### CMDB relationship loss

The true value of a CMDB is the relationship graph, not the list of CI records. ICD stores CI-to-CI relationships in `CIRELATION`. The target platform's CMDB uses a different relationship model. ServiceNow uses `cmdb_rel_ci` with `parent`, `child`, and `type` references; JSM Assets uses typed relationship links between object schema entries. Neither maps 1:1 to Maximo's `CIRELATION` structure.

**Maximo `CIRELATION` → ServiceNow `cmdb_rel_ci` mapping (example meanings):**

| ICD relationship meaning | ServiceNow `cmdb_rel_type` (name) | ServiceNow direction |
|---|---|---|
| Runs on | Runs on::Runs | child → parent |
| Hosted on | Hosted on::Hosts | child → parent |
| Connected to | Connected by::Connects | bidirectional |
| Depends on | Depends on::Used by | child → parent |
| Backed up by | Backed up by::Backs up | child → parent |
| Virtualized by | Virtualized by::Virtualizes | child → parent |
| Member of | Members::Member of | child → parent |
| Managed by | Managed by::Manages | child → parent |

This is a partial list of example meanings, not ICD codes. Your relationship types are identified by `RELATIONNUM`, and many deployments add their own. Run `SELECT DISTINCT RELATIONNUM FROM CIRELATION` before building the mapping table — do not assume any default list covers your environment.

**Load sequence for CMDB migration to ServiceNow:** Load all CI records first, storing the Maximo `CINUM` as a correlation ID in a custom field (e.g., `u_maximo_ci_id`). After all CIs are loaded, query the `sys_id` for each using the correlation ID, then load `CIRELATION` rows as `cmdb_rel_ci` records referencing the new `sys_id` values. Any `CIRELATION` row where the parent or child CI does not exist in the target is rejected — this is why CI records must be fully loaded before relationship records.

**ServiceNow IRE payload format:** When loading CIs into ServiceNow via the Identification and Reconciliation Engine, format the payload to trigger IRE validation. A minimal IRE-compliant payload for a Maximo server CI:

```json
{
  "items": [
    {
      "className": "cmdb_ci_win_server",
      "values": {
        "name": "MYSERVER01",
        "ip_address": "10.0.1.50",
        "u_maximo_ci_id": "MYSERVER01"
      },
      "related": []
    }
  ],
  "relations": []
}
```

POST this to `/api/now/identifyreconcile`, and set the `sysparm_data_source` query parameter to one of your instance's `discovery_source` choice values; without it, ServiceNow sends the payload to its incomplete payloads table ([servicenow.com](https://www.servicenow.com/docs/r/api-reference/rest-apis/c_IdentifyReconcileAPI.html)). IRE will match against existing CIs using identification rules before creating duplicates. For the full relationship load, populate the `relations` array after all CI records are confirmed in the target — do not attempt to load CI records and their relationships in a single payload if any referenced CI may not yet exist.

### Ticket-to-change cross-references

In ICD, a service request can be promoted to an incident, which can spawn a change. These cross-references span `TICKET` and `WORKORDER` via `ORIGRECORDID` and `ORIGRECORDCLASS`, and bidirectionally via `RELATEDRECORD`. If you load tickets and changes independently without rebuilding these links, you lose the audit trail showing how an incident drove a change.

**Fix:** Extract `ORIGRECORDID`, `ORIGRECORDCLASS`, and all rows from `RELATEDRECORD` where `RECORDKEY` or `RELATEDRECKEY` matches your record set. After loading both datasets into the target, run a reconciliation pass using a mapping table of old ICD IDs to new target IDs to re-link records.

### Work log ordering and orphaning

Work logs are stored in `WORKLOG`, linked via `RECORDKEY` and `CLASS`. Each work log carries a `clientviewable` boolean that determines where it maps in the target system:

- `clientviewable = 1` → **customer-visible comments** (ServiceNow: `comments` field; Additional Comments)
- `clientviewable = 0` → **internal work notes** (ServiceNow: `work_notes` field; not visible to requesters)

If you load these out of order, the target displays a disjointed timeline. Sort `WORKLOG` entries by `CREATEDATE` within each parent record before loading.

Communication logs (`COMMLOG`) add another layer. A single incident's full communication history can include entries where `OWNERTABLE` = 'SR' (the originating request), 'INCIDENT' (the incident itself), 'PROBLEM' (a related problem), and 'WOCHANGE' (a resulting change). A query filtered only on `OWNERTABLE='INCIDENT'` silently drops all entries owned by related record types. 

**Fix:** Walk the full related-record chain for each ticket:

1. Start with the incident's `TICKETID`.
2. Query `RELATEDRECORD` to find all related SRs, problems, and changes.
3. Collect `COMMLOG` rows where `OWNERID` and `OWNERTABLE` match any record in that chain.
4. Collect `WORKLOG` rows where `RECORDKEY` and `CLASS` match any record in that chain.
5. Merge all entries, sort by `CREATEDATE`, and load as a unified conversation thread on the target — with metadata indicating the original `OWNERTABLE` for audit purposes.

### Classification hierarchy mismatches

ICD uses `CLASSSTRUCTURE` for hierarchical classification of tickets, CIs, and assets. The `CLASSSTRUCTURE` table is self-referential via a `PARENT` column and can go five or more levels deep. Most ITSM platforms use two or three levels (category → subcategory → item). Deep trees must be mapped before migration — there is no automated solution. The mapping decision affects SLA assignment rules, automation triggers, and reporting categories on the target platform.

Extract the full `CLASSSTRUCTURE` tree before beginning any other mapping work. Present it to the business stakeholders who own SLA and routing rules — they must sign off on the flattened mapping before the migration begins, because changing it after load requires re-processing every ticket that carries a classification.

### Attachment volume and pipeline

Large ICD environments can have tens of gigabytes of attachments. The extraction process for each attachment:

1. Query `DOCLINKS` for the specific `OWNERTABLE` + `OWNERID` combination.
2. Check `DOCINFO.URLTYPE` — handle file and URL attachments differently (see table above).
3. For `FILE` type, resolve the path in `DOCINFO.URLNAME`, using `mxe.doclink.path01` to map it to a web URL.
4. Download the binary (from file server or API stream).
5. Validate MIME type against target platform's allowed types.
6. POST to target attachment API (e.g., ServiceNow: `POST /api/now/attachment/file?table_name=incident&table_sys_id={sys_id}`).
7. Log failures (size limit exceeded, unsupported MIME type) separately — do not fail the parent ticket load.

Attachment migration is typically the longest-running phase and the most likely to surface platform-side rejections. ServiceNow sets its maximum attachment size, in megabytes, with the `com.glide.attachment.max_size` property, which falls back to 1024 when unset ([servicenow.com](https://www.servicenow.com/docs/r/oL66E_cwDD_tnWQYzYPRdA/HQcj4mw24iZNE7w9kMaDsg)). Check its value on the target instance before migration begins.

### Delta sync mechanism

The step most critical to a clean cutover is also the least obvious. After the bulk migration completes, records continue to be created and modified in ICD during the validation window. The delta sync must capture these without re-loading the full dataset.

The correct mechanism for delta syncing from Maximo:

1. **Record the cutover timestamp** at the start of the bulk migration (not the end).
2. **Poll `CHANGEDATE` and `CHANGEBY`** on `TICKET`, `WORKORDER`, `ASSET`, and `CI` tables. Every Maximo record carries a `CHANGEDATE` column updated on any modification. Query: `WHERE CHANGEDATE >= :bulk_migration_start_timestamp`.
3. **For new tickets and work orders,** also check `REPORTDATE` >= bulk migration start.
4. **For `WORKLOG` and `COMMLOG`,** poll by `CREATEDATE` >= cutover timestamp — new log entries arrive as new rows.
5. **For attachments,** poll `DOCLINKS.CREATEDATE` >= cutover timestamp.
6. **Apply upsert logic** in the target: if the record's legacy ID already exists (from the bulk load), update it; if not, insert it.

The Maximo Integration Framework's publish channels and queues are an alternative for near-real-time sync but requires Integration Framework configuration that may not be in place on a decommissioning ICD instance. `CHANGEDATE` polling is more reliable for the migration cutover scenario.

## How long does an IBM Control Desk data migration take?

Keep two clocks apart: the data migration (extraction, transformation, loading, and validation), and the customer's own replatform, workflow rebuild, and implementation project.

For the **data migration** itself:

| Volume | Complexity | Estimated duration |
|---|---|---|
| Under 10,000 records | Small datasets | Under 24 hours |
| Most ICD environments | Varies with CMDB depth, sites, and attachments | 1–5 business days, depending on data volume, complexity, and API rate limits |
| Several hundred thousand records, or 5,000+ documents | Custom engagement with phased bulk + delta sync | Scoped individually |

The CI-to-relationship ratio is the strongest volume predictor. A CMDB with 5,000 CIs and 50,000 `CIRELATION` rows is a fundamentally different project than 5,000 CIs with 500 relationships — the relationship graph validation alone scales super-linearly with relationship count.

> [!WARNING]
> The figures above cover only the data migration ClonePartner performs. Your internal effort to configure the new ITSM platform, rebuild workflow automations, train staff, and complete UAT is a separate project on your own timeline, and ClonePartner does not perform it. With sustained support ending on December 31, 2026, start discovery now.

## Step-by-step: migrating tickets, CMDB, and assets from ICD

### Step 1: Inventory and scope

Query your ICD database for record counts by type. This determines volume tier and effort:

```sql
SELECT 'Incidents' as type, COUNT(*) FROM TICKET WHERE CLASS='INCIDENT'
UNION ALL SELECT 'SRs', COUNT(*) FROM TICKET WHERE CLASS='SR'
UNION ALL SELECT 'Problems', COUNT(*) FROM TICKET WHERE CLASS='PROBLEM'
UNION ALL SELECT 'Changes', COUNT(*) FROM WORKORDER WHERE WOCLASS='CHANGE'
UNION ALL SELECT 'Assets', COUNT(*) FROM ASSET
UNION ALL SELECT 'CIs', COUNT(*) FROM CI
UNION ALL SELECT 'CI Relationships', COUNT(*) FROM CIRELATION
UNION ALL SELECT 'Work Logs', COUNT(*) FROM WORKLOG
UNION ALL SELECT 'Attachments', COUNT(*) FROM DOCLINKS;
```

Also record the distinct `SITEID` values across `TICKET`, `WORKORDER`, `ASSET`, and `CI` — multi-site deployments require namespace planning before any other work.

### Step 2: Establish API or database access and build field mappings

Establish API access (or database access for on-premises) to ICD and the target platform. Build explicit field mapping tables before writing any extraction code:

**Ticket field mapping (ICD → ServiceNow example):**

| ICD Column | ICD Table | Target Table | Target Column | Transform required |
|---|---|---|---|---|
| `TICKETID` | `TICKET` | `incident` | `u_icd_ticket_id` | Store as correlation ID |
| `CLASS` | `TICKET` | (determines table) | — | 'INCIDENT'→`incident`, 'SR'→`sc_req_item`, 'PROBLEM'→`problem` |
| `DESCRIPTION` | `TICKET` | `incident` | `short_description` | None |
| `DESCRIPTION_LONGDESCRIPTION` | `TICKET` | `incident` | `description` | Strip HTML if present |
| `REPORTDATE` | `TICKET` | `incident` | `opened_at` | Timezone conversion |
| `STATUS` | `TICKET` | `incident` | `state` | Domain lookup via `SYNONYMDOMAIN` |
| `OWNER` | `TICKET` | `incident` | `assigned_to` | Person lookup by email |
| `OWNERGROUP` | `TICKET` | `incident` | `assignment_group` | Group lookup by name |
| `PRIORITY` | `TICKET` | `incident` | `priority` | Numeric domain mapping |
| `CLASSSTRUCTURE` | `TICKET` | `incident` | `category`/`subcategory` | Hierarchy flattening required |

Map status values by querying `SYNONYMDOMAIN` where `DOMAINID` is `SRSTATUS` or `INCIDENTSTATUS` (tickets) or `WOSTATUS` (changes) — ICD's internal codes (`QUEUED`, `INPROG`, `RESOLVED`, `CLOSED`, `CANCELLED`) are stored differently from their display values and will not match the target's status model.

### Step 3: Extract in dependency order

Load order is non-negotiable. The safe sequence:

1. **Persons and groups** (`PERSON`, `PERSONGROUP`) — no dependencies
2. **Locations and sites** (`LOCATIONS`, `SITE`, `ORGANIZATION`) — no dependencies
3. **Domain values** (`SYNONYMDOMAIN`, `ALNDOMAIN`) — needed for status/priority transformation
4. **Classifications** (`CLASSSTRUCTURE`) — self-referential; load parents before children using recursive ordering by level depth
5. **Assets** (`ASSET`) — depend on locations, persons
6. **CIs** (`CI`) — depend on assets, classifications
7. **CI relationships** (`CIRELATION`) — depend on all CIs existing in target
8. **Service requests, incidents, problems** (`TICKET`) — depend on persons, CIs, assets
9. **Changes, releases, activities** (`WORKORDER`) — depend on tickets for cross-references
10. **Work logs and communication logs** (`WORKLOG`, `COMMLOG`) — depend on parent tickets/changes existing in target
11. **Attachments** (`DOCLINKS`) — depend on all parent records existing in target

Loading out of order means broken foreign key references. CI relationships loaded before CIs exist produce constraint violations. Attachments loaded before parent records exist produce orphaned files.

### Step 4: Sample migration and validation

Run a sample migration with records that exercise every relationship type: an incident with CI linkages via `MULTIASSETLOCCI`, a change spawned from a ticket (with `ORIGRECORDCLASS` populated), work logs spanning related records, and a CI with `CIRELATION` rows. Validate with:

- Record-count parity: source ICD count vs. target count per type
- Field-level spot checks on 10% sample: compare source field values to target field values
- Referential integrity: every `CIRELATION` row references CIs that exist in the target
- Conversation completeness: work log count per ticket matches between source and target
- Attachment reachability: attachment URLs in the target are resolvable and serve the correct file

### Step 5: Full migration and delta sync

Run the bulk migration during the working days before go-live, while agents keep working in ICD. Go live on a Monday morning: freeze ICD before the working day starts, run the final delta sync using the `CHANGEDATE` polling methodology described above (about 30 minutes for changed records only), and have agents log in to the new platform that morning. The cutover timestamp must be recorded at the start of the bulk migration run, not the end.

For environments with continuous ticket flow, run a background sync using 15-minute `CHANGEDATE` polling windows during the validation period, then perform a fast final delta at cutover. Validate the delta record count against the number of records with `CHANGEDATE` >= bulk migration start before confirming the cutover is complete.

### Step 6: Post-migration validation

Multi-stage validation:

- **Record-count parity** across all entity types
- **Field-level validation** on a statistical sample (minimum 10% of records per type)
- **Referential integrity checks** across the full relationship graph — CI→incident links via `MULTIASSETLOCCI`, ticket→change cross-references, asset hierarchies, CI relationship topology
- **Conversation thread validation** — spot-check that work log count and ordering matches between source and target
- **Attachment validation** — confirm attachment file is retrievable on target for a sample of records with known attachments

## Security and compliance

When extracting sensitive ITSM data, security controls should be verified, not assumed. Relevant controls for an ICD data migration:

- **Encryption in transit:** All API calls should use TLS 1.2 or higher. If using direct SQL extraction, the database connection should be encrypted (TLS on the Db2, Oracle, or SQL Server connection).
- **Encryption at rest:** Staging data should be stored with AES-256 encryption. Verify that any intermediary storage (S3 buckets, local staging servers) has encryption at rest enabled — this is not the default in all configurations.
- **Data minimization:** Extract only the fields required for migration. Do not stage full TICKET payloads including personally identifiable information (PII) unless the target platform will receive that data.
- **Retention:** Staging databases and extracted flat files should be deleted within 30 days of migration completion. Document the deletion for GDPR and CCPA purposes.
- **Access control:** Migration credentials (ICD API keys, target platform service accounts) should be provisioned with minimum required scope and rotated immediately after migration completes.

## Should you handle this migration in-house or use a service?

**Handle in-house if:**
- Fewer than 10,000 total records
- Single-site deployment (`SITEID` count = 1)
- Flat CMDB (fewer than 5,000 `CIRELATION` rows)
- No cross-ticket or ticket-to-change cross-references to preserve
- Engineering team has Maximo DBA access and Python/scripting capability

**Use a managed migration service if:**
- Complex CMDB topology (deep `CIRELATION` graph, custom relationship types)
- Multi-site deployment with namespace collision risk
- Hundreds of thousands of records with attachment volumes in the tens of gigabytes
- Hard December 2026 deadline with no tolerance for a failed first attempt
- Compliance requirements (HIPAA, SOC 2 audit evidence) that require documented migration controls

The cost of a failed first attempt — re-extraction, re-mapping, re-loading, and re-validation — almost always exceeds the cost of a managed engagement. The delta sync complexity and CMDB relationship validation are where in-house efforts are most likely to produce silently broken data that is not caught until post-go-live.

For a broader look at migration approaches, see our [help desk data migration checklist](https://clonepartner.com/blog/blog/help-desk-data-migration-checklist) and our analysis of [in-house vs. outsourced data migration](https://clonepartner.com/blog/blog/in-house-vs-outsourced-data-migration).

## What happens if you miss the December 2026 deadline?

The software does not stop working on January 1, 2027. But running unsupported ITSM software creates compounding risk:

- **Security vulnerabilities go unpatched.** Sustained support already excludes new security patches, and after December 31, 2026 IBM provides no fixes, patches, or security updates at all. Every month on unsupported software widens the attack surface against a platform that holds sensitive incident, change, and asset data.
- **Compliance exposure.** SOC 2, ISO 27001, and regulatory audits flag unsupported software as a control deficiency. For organizations handling PHI, running an unsupported ITSM platform complicates HIPAA safeguard attestation.
- **No escalation path.** When something breaks — and eventually it will — IBM will not help. You are relying entirely on internal Maximo expertise or third-party consultants.
- **Integration rot.** As connected systems (email servers, LDAP/AD, monitoring tools) update, ICD's static integration layer will start failing. No patches means no compatibility fixes.

Treat December 31 as the date after which every week of delay adds uninsured risk, not as a cliff edge where everything breaks at midnight. Start scoping now.

> IBM Control Desk support ends December 31, 2026. Whether you're moving to Maximo IT, ServiceNow, Jira Service Management, or another platform, a 30-minute scoping call will tell you exactly what's involved — data volume, timeline, and a fixed price.
>
> [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 does IBM Control Desk end of support happen?

IBM Control Desk 7.6.1.x standard support ended September 30, 2025. Sustained support — the final stage — ends December 31, 2026. After that date, IBM provides no fixes, patches, or security updates, and no support, maintenance, or escalation options.

### What is the replacement for IBM Control Desk?

IBM's recommended successor is Maximo IT, an add-on to the Manage application within IBM Maximo Application Suite (MAS). IBM describes it as a lift-and-shift of ICD 7.6.1.5 where all ITIL processes remain the same. Organizations not staying on the IBM stack commonly migrate to ServiceNow, Jira Service Management, or Freshservice.

### Can I export IBM Control Desk tickets to CSV?

You can export top-level ticket fields to CSV, but native CSV exports drop relational data like work logs, inline attachments, status history, and CI relationships. A production migration requires API or database extraction to preserve this data.

### How long does an IBM Control Desk data migration take?

The data migration itself — extraction, transformation, loading, and validation — typically completes 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. Very large migrations take longer, and ClonePartner gives a timeline after scoping. This is separate from your own replatforming project, which ClonePartner does not perform.

### Can I migrate IBM Control Desk data to ServiceNow?

Yes. ICD's ticket classes (SR, Incident, Problem), changes, assets, and CMDB CIs can be mapped to ServiceNow's task table hierarchy and CMDB. The main challenges are converting Maximo's shared TICKET table into ServiceNow's separate tables and rebuilding CI relationships in ServiceNow's cmdb_rel_ci structure.