Moving to ServiceNow Customer Service Management: Migration Considerations

This page covers how to move an existing service desk onto ServiceNow Customer Service Management. It sets out the decisions to make before cutover: what to inventory, which processes to redesign, how to migrate and cleanse customer and ticket data, and whether to cut over in one step or in phases.

Inventory Current State and Define Target Capabilities

Before planning the migration, document what you run today. If you operate service desk and field service separately, you may need to integrate them into a unified CSM instance. If customer interactions today are spread across email, ticketing systems, and knowledge repositories, identify which CSM capabilities will consolidate this traffic.

List every customer-facing application and system: ticketing systems, knowledge bases, self-service portals, reporting tools, integrations with email or chat. For each, document how many users access it daily, what data lives there, and which team owns it. This inventory becomes your migration scope. If you discover a system you did not know existed, you have a risk—teams may use workarounds you did not plan for.

Map Current Processes and Redesign for CSM

Customer Service Management reshapes service desk workflows. Document current incident and request processes: how do customers report issues, who owns triage, how are escalations handled, what SLAs apply. Identify where these processes conflict with CSM’s opinionated workflow model.

For example, if your current process allows field service technicians to self-assign tasks without approval, but CSM’s best practices require queuing and work-balancing logic, you need to decide: do you adopt CSM’s process or build custom logic to preserve your current workflow? Early decisions about process redesign prevent later configuration rework.

Map data flows. Where does customer information originate—CRM, HR system, manual entry? Which teams need access to customer history? How does CSM integrate with billing or contract management to show customers their account status? Data flow mapping reveals dependencies and integration points that must work before cutover.

Plan Data Migration and Cleansing

Customer and ticket data must be migrated from legacy systems. Plan the migration in phases: extract data from the current system, transform it into CSM’s schema, validate the results, then load into the target environment.

Expect data quality issues. Customer records may have incomplete phone numbers or email addresses. Ticket histories may include private internal notes that should not be migrated. Assign a team to review and cleanse data during transformation; do not load bad data and try to fix it in production. A bulk ticket load full of low-quality records creates support burden on your team and confusion for customers who see corrupted histories.

Cutover Options and Timing

Choose a cutover strategy based on your tolerance for downtime and the complexity of your environment. Big-bang cutover migrates all data and users in a single window, typically over a weekend. This is fastest but risky; if issues arise, rolling back is difficult. Big-bang cutover suits small deployments with simple integrations and a small customer base.

Phased cutover runs the old and new systems in parallel for a period, gradually moving customers to CSM. This is slower and more complex—two systems must be maintained simultaneously—but allows you to catch issues with a subset of users before full cutover. Pilot cutover with a single customer group or business unit first, validate that customer experience is maintained, then roll out to remaining groups.

Parallel running requires reconciliation logic. If a customer submits a ticket while one team still uses the old system and another team uses CSM, both systems record the ticket. Reconciliation must eliminate duplicates and ensure no tickets are lost. Plan reconciliation before cutover, not after.

Risks and Mitigation

Service continuity risk is highest: a failed cutover can leave customers unable to report issues. Mitigate by having a detailed rollback plan (restore backups, communicate to customers, revert to the old system) and testing it before cutover. Ensure old system backups are retained and can be quickly restored if needed.

Integration risk arises when CSM must integrate with systems like CRM, billing, or ticketing gateways. If integrations fail, customers may see incomplete information or requests may not route correctly. Test each integration thoroughly in a production-like environment before cutover. Have a fallback approach for each integration (manual workaround if auto-sync fails).

User adoption risk occurs when teams trained on the new system have forgotten training by cutover day. Stagger training close to cutover. Do not train everyone in week one if cutover is week eight; retraining will be necessary. Pair live support and job aids on day one so teams do not have to rely solely on memory.

Validation and Sign-Off

Develop a validation checklist before cutover. Confirm data counts match between old and new systems. Test critical workflows (create incident, route to queue, assign to technician, close with satisfaction survey). Validate that integrations are running and data is flowing. Have customer-facing teams test self-service portal usability with real customers or user advocates.

Obtain business sign-off before cutover: confirm that CSM configuration meets requirements, data migration is complete, integrations are working, and training is done. Document any configuration gaps or accepted risks; do not launch hoping to address them after cutover.

What a Migration Actually Moves, and What It Should Leave Behind

A team leaving a legacy case tool or a spreadsheet-based customer desk tends to think about migration as moving cases. In practice, a customer service record is a bundle: the case itself, the account and contact it hangs from, the activity history, the attachments, the SLA state at the moment of transfer, and the decisions recorded in notes. Each part has a different risk. The useful first decision is not how much data to move, but which parts must come across as live records, which can arrive as read-only history, and which should be left in the old system until it is no longer needed.

A common and sound pattern is to move open and recently closed cases as live records, move older closed cases as archived history where the audience is mainly reporting, and leave very old records in an archive outside the new platform. This keeps the active queue clean without pretending that a decade of closed tickets must be re-worked inside a new tool.

Object-by-Object Treatment

The table below sets out how each part of a customer record is usually handled. The right answer for your business depends on your retention obligations and reporting needs, so treat the middle column as a default to challenge, not a rule.

A Cutover Sequence That Keeps Customers Served

The sequence below assumes a planned cutover rather than a single overnight switch. Many teams cannot stop taking requests for a day, so the plan has to cope with cases arriving on both systems during the transition.

1. Freeze the mapping of fields and states between the old and new systems, and have the operations lead sign it off line by line.
2. Clean the source data for duplicate accounts, retired owners and invalid states before the first test import, not during the final load.
3. Run a full test migration into a non-production instance and reconcile counts by queue, state and owner against the source.
4. Decide the intake switch point. Have a single rule for which system receives a new request on the cutover day, and tell the front-line team in writing.
5. Load the open cases as the final step before the switch, then run a reconciliation of open case counts and owners.
6. Keep the old system read-only but available for a defined period, so an agent can check a historic case without guessing.
7. Review the first week of cases daily, looking for routing, owner and SLA anomalies that the test import would not have shown.

Parallel Running Versus a Clean Break

Running two systems in parallel feels safer, and sometimes it is. It is also expensive in attention, because agents must decide which system a request belongs in and supervisors must reconcile two queues. A clean break works better when the case volume is manageable, the open case count is small enough to reconcile by hand, and the team has rehearsed the switch. Parallel running works better when a single queue cannot be moved without breaking an integration or a regulatory reporting cycle. The choice should be made per queue where possible, not for the whole department at once.

Signs the Migration Is Going Wrong

The early warning signs are often in the reports, not in complaints. Watch for open case counts that drift between the two systems, for a spike in cases with no owner, and for SLA breaches that cluster on the migration date. Any of these means the mapping or the cutover rule has a gap, and the answer is to pause new loads and reconcile, not to push more volume through and sort it out later. The testing and acceptance checklist covers the evidence to gather before the switch.

Can we migrate attachments in bulk without checking them?

It is safer to sample them first. Check a range of case types, large files and unusual formats before committing to a bulk load, because a failed attachment is often only noticed when a customer asks for it.

Should historic SLA data come across at all?

Often the historic clocks are better kept in the old system or in a reporting extract. The new platform should start SLA measurement from the cutover with a clear rule, so the first reports are not polluted by restarted timers.

How long should the old system stay available?

Long enough for the team to stop needing it for live work, and for any retention or audit request that could reasonably arrive. Set that period when the cutover is planned, not when the old system is being switched off.

Who should approve the field mapping?

The operations lead who owns the queues, with the platform administrator confirming it is buildable. A mapping approved only by the technical team often moves data correctly into the wrong business meaning.

Next Step

Volumes differ enough between desks that the cutover sequence above should be re-checked against your own numbers.