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). 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.

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). IBM formally announced the transition in September 2023 (ibm.com). 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):

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.)

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:

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).
• 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).

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). CI-to-CI relationships live in the CIRELATION table, which defines upstream/downstream dependencies with the following structure:

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). 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). 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.

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 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 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).

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:

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). 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). 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:

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).

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):

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):

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:

{
  "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). 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). 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:

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.

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:

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):

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 and our analysis of 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.