Migrating from CA Service Desk to ServiceNow

Leaving CA Service Desk means moving incident, request, change and asset data into tables that are structured differently, and rebuilding the reports and integrations that teams depend on. This page covers the pre-migration assessment, data inventory and mapping, process and workflow mapping, the cutover options, validation and reconciliation, training and change management, integration rework, and timeline and budget. The later sections focus on the hardest part of the move: asset records and their relationships, how their attributes map to ServiceNow tables and owners, the procedure for the first asset load, and what goes wrong when relationships are treated as notes.

Pre-Migration Assessment

Start by auditing your current CA Service Desk environment. Document: incident volume (daily, monthly), average incident lifespan, how many users, customizations, integrations with other tools. Understand your data: is it clean and consistent, or does it have quality issues that migration would amplify? Identify critical reports and dashboards that leadership depends on; these must be recreated in ServiceNow or you risk management resistance.

Assess team skills: do you have CA Service Desk expertise on staff, and can they learn ServiceNow? Do you have in-house development capability, or will you need a partner? Migration success depends partly on your team’s ability to adapt and adopt new tools.

Data Inventory and Mapping

CA Service Desk stores incidents, requests, changes, problems, and configuration items. For each, determine: how much data do you need to migrate? How far back (all history or just active records)? What fields need to map to ServiceNow? CA Service Desk and ServiceNow use different table structures and field names; migration requires careful mapping so data does not get lost or corrupted.

Incidents in CA Service Desk map to Incident Management in ServiceNow, but not all fields map one-to-one. Custom fields in CA Service Desk may need to become standard fields in ServiceNow, or they may not have a destination and need to be archived. Categorization fields may use different lists; you need translation tables to convert CA categories to ServiceNow categories.

Pay special attention to configuration items and asset data. If you track asset inventory in CA Service Desk, you need to decide: does this move to ServiceNow’s asset management module, or does it stay in a separate tool? How do you link incidents to assets after migration?

Process and Workflow Mapping

Document your current CA Service Desk workflows. How do incidents flow from creation to resolution? What approvals are required? What escalation rules are in place? ServiceNow’s default ITSM workflows are often similar to CA Service Desk, but details differ. Some workflows may need simplification for ServiceNow; others may need to be built as customizations.

Identify process improvements you want to make during migration. Migration is expensive and disruptive, so it is the time to also improve processes. Ask teams: what is working well in CA Service Desk? What would you change? Use migration as an opportunity to adopt better practices, not just to reimplement the old system in new software.

Cutover Approach Options

Big bang: Migrate all data and switch everything to ServiceNow on a specific date. This is faster and simpler, but risky if ServiceNow is not fully ready or if data migration has issues. Only choose big bang if your CA Service Desk environment is simple and you are confident in the migration plan.

Phased cutover: Migrate by business unit or geography. Early cutover users gain experience and identify issues while later groups can learn from their experience. This is lower risk but extends the transition period (teams must run both systems in parallel for a time).

Parallel run: Run both systems for a transition period. Incidents are logged in both CA Service Desk and ServiceNow. This is safest but most expensive. Only choose this if high availability is critical and you cannot afford any incident management disruption.

Data Validation and Reconciliation

Before cutting over, validate that migrated data is accurate. Run incident counts and sample records: do they match between CA Service Desk and ServiceNow? Check that custom fields made the transition. Verify that automation rules and escalations work the same way in ServiceNow.

Reconciliation after cutover: immediately after switching to ServiceNow, incidents will briefly spike in creation (dual entry, training, confusion). Be prepared for that. Monitor data quality in ServiceNow closely for the first two weeks; catch issues quickly before they propagate.

Training and Change Management

Teams are comfortable with CA Service Desk. ServiceNow will feel different: different terminology, different UI, different workflows. Budget significant time for training and change management. Some teams will resist; acknowledge that and support them through the transition. Identify super-users early and train them first; they become advocates and informal support for others.

Create quick reference guides for common tasks: “How do I update an incident in ServiceNow?” “How do I search for incidents?” “Where is my dashboard?” These small guides reduce support burden.

Integration Rework

Tools that integrated with CA Service Desk (monitoring systems, CMDB, knowledge management) need to be reconnected to ServiceNow. This is usually not complex technically (both systems have API), but it requires effort and testing. Plan to rework integrations before or immediately after cutover so you do not lose visibility into incidents.

Timeline and Budget

CA Service Desk to ServiceNow migrations take longer for complex estates. Big bang cutover is usually faster but riskier, while phased cutover takes longer. Budget professional services for data migration, custom development, and training. Plan for unexpected issues during cutover, and for a difficult period soon after going live.

Asset records and relationships are the hard part of leaving CA Service Desk

Teams that ran CA Service Desk for a long time often have two systems of record in one: tickets, and an asset estate that the tickets point at. The ticket history moves across with reasonable effort. The asset estate is where a migration either earns trust or loses it. Servers, applications and network devices in the old platform carry relationships to owners, locations, support groups and to each other, and those relationships are often the reason a change request could be assessed at all. Before any load, decide whether the asset list is being migrated as a register, as a configuration model, or as both. Those are different goals with different owners.

Mapping asset attributes to ServiceNow tables and their owners

An attribute that looks identical on both sides can mean something different. A status of in service may describe whether a device is powered on in one platform and whether it is supported under a contract in the other. The mapping step is where you settle those meanings, and the table below shows the decisions that cause most rework.

Procedure for the first asset load

• Agree the source of truth for each attribute family in writing, with a named owner for disputes.
• Load a small, known set of assets for one business service, including its relationships, into a non-production instance.
• Reconcile the loaded records against the old platform’s report for the same service, not against a general count.
• Check that no device appears twice after the identification rules run, and that retired items are either excluded or clearly flagged.
• Only then extend the load to the rest of the estate, one service at a time.

What goes wrong when relationships are treated as notes

A common shortcut is to copy the old relationship as a text field, because it is quicker than resolving each reference. That shortcut removes the reason for having a configuration model. Change impact, service mapping and incident routing all depend on references that the platform can walk. A text note reads correctly on a record and then does nothing when a change is raised against the service it describes. If a relationship cannot be resolved to a real configuration item, record it as an open item for the service owner rather than writing it as a string and calling it migrated.

A second failure is loading everything. Old estates often include development hosts, test hosts and devices that were decommissioned before the last audit. Loading them makes the new platform look full of noise, and the people who must trust it start filtering it out by hand, which is the behavior the migration was supposed to end.

When the asset estate is not in a condition that supports an honest load, it is reasonable to migrate tickets and history first and bring the configuration data in later, once the owners have cleaned it. That sequence is slower on paper and far less damaging in practice.

Questions about the asset side of the move

Should we keep CA Service Desk running read-only for asset history?

Often yes, for a defined period that covers the audit and financial questions you expect to face. Export the history you need in a form that can be queried without the old application, and write down what the export does and does not include.

Who should decide whether a retired asset is loaded?

The asset owner and finance together. Operations knows whether a device is still physically present, and finance knows whether the cost or depreciation record still matters.

How do we handle assets that belong to more than one service?

Model the shared dependency once and link it to each service, rather than copying the device under each one. The copy is what can produce impact analysis that looks plausible and is wrong.

The reconciliation logic that prevents duplicates is set out in the reconciliation rules note, the matching service is described on the duplicate control service page, and the other routes are in the migration hub.