We supported a healthcare client in the migration of two ITSM tools, C2 and Guide TI, to ServiceNow, using process mining with Celonis to understand the current state and secure the transition. This data-driven approach accelerated the project by several weeks by providing immediate access to observable facts rather than relying on partial assumptions gathered during workshops. It also significantly reduced risks throughout the project, thanks to a precise and detailed understanding of how the existing processes were actually executed in the legacy systems.
Both tools were on-premise systems containing valuable information about real operations: statuses, timestamps, assignment groups, and the paths taken by tickets and work orders. The goal of the initiative was not to reinvent workflows, but rather to reconstruct what was truly happening from the data, and then use that understanding to prepare a more reliable, faster, and clearer migration to ServiceNow for the teams.
To achieve this outcome, several structured steps were implemented, ranging from extracting data from the existing systems to analyzing the actual process flows and preparing the target configuration in ServiceNow.
1. Starting Point: Two Systems, Two Flows to Migrate
Before ServiceNow, the client relied on C2 for ticket management and Guide TI for work order management. This setup worked, but understanding actual workflows relied heavily on team experience rather than factual visibility. For the migration, we needed to answer simple, concrete questions: which steps are actually used, how long they take, and how tickets flow between assignment groups. This need was the main driver for using Celonis.
2. Connecting to C2: Extraction from an On-Premise Database
Since C2 was an on-premise source, we installed an agent on the database server to enable data extraction to Celonis. The scope was process mining-oriented: ticket identifier, timestamps, statuses, assignment groups, and useful fields for analysis (including the field identifying ticket type). The objective was to obtain a usable data stream to reconstruct tickets’ actual lifecycle, without relying solely on documentation or declarative workshops.
3. Connecting to Guide TI: On-Premise Extraction for Work Orders
Since Guide TI was also on-premise, we applied the same approach: using the same extraction agent to feed Celonis. The data leveraged concerned work orders, with their steps and associated information: creation, status changes, assignment group changes, and processing milestones. The objective was to understand how teams handled these orders, how they progressed over time, and where waits or restarts occurred.
4. Modelling: Building Celonis Event Logs
Once data was extracted, we built the event logs used by Celonis. Each ticket (C2) and each work order (Guide TI) was defined as a case, and status and assignment changes as timestamped events. We associated these events with available system information (status, assignment group, and the type field on C2’s side) to analyze paths, variants, and turnaround times. This structuring generated an exploitable digital twin to prepare the ServiceNow migration.
5. Digital Twin: Making Actual Execution Visible
From the event logs, Celonis reconstructed a view of the process as it actually executed: step sequences, most frequent paths, variants, and time between steps. This representation served as a common basis for discussing existing operations and preparing the target state. It also visualized where tickets spend the most time (long statuses, wait periods) and objectified path differences across cases explicit. The main benefit was grounding the migration in observable, data-driven facts.
6. C2 Specificity: Incidents and Requests in a Single Module
An important point on C2: incidents and requests were managed in the same module, distinguished only by a field. In other words, ticket content was processed in a common structure, with an indicator distinguishing incident vs. request. In ServiceNow, the logic differs: incidents and requests rely on distinct modules designed for these purposes. This difference was central to the migration, requiring a thorough understanding of C2’s actual content (via the field) to translate it correctly into ServiceNow.
7. Comparison and Target Preparation: Statuses and Assignment Groups
By analyzing C2 tickets and Guide TI work orders, we observed paths and transitions between statuses and assignment groups. This reading helped prepare the ServiceNow target: which statuses should exist, how to represent processing steps, and how to organize groups to maintain coherent operational logic. The objective was not to eliminate business steps, but to avoid ambiguities during implementation: clarifying mappings between legacy statuses and those to be used in ServiceNow.
8. ServiceNow Migration: Configuration and Post-Cutover Monitoring
Based on this understanding, we supported ServiceNow configuration to reflect existing flows, particularly the incident / request separation and the representation of steps from C2 and Guide TI. After cutover, Celonis’ value remains strong: verifying that expected paths are actually executing, tracking actual turnaround times, and identifying gaps between the defined target and field usage. This secures adoption and establishes sustainable management rather than a “one-shot” project.
Conclusion
This project illustrates the value of process mining with Celonis in system migration: connecting on-premise sources (C2 and Guide TI), reconstructing actual paths from statuses and assignment groups, then using this vision to prepare a more reliable ServiceNow migration. The key ITSM point was transitioning from a C2 where incidents and requests coexist in a single module (distinguished by a field) to a ServiceNow organization that naturally separates them. Result: a better-controlled migration and a clearer model for teams.