Migrating from Salesforce Service Cloud (for IT use cases) to ServiceNow

Moving IT cases from Salesforce Service Cloud to ServiceNow means deciding which records belong to the IT service before any data moves. This page helps you split IT cases from customer cases, map queues and entitlements, and plan the cutover.

Understanding the Platform Differences

Salesforce Service Cloud is built for service delivery, customer support, and complex multi-step workflows. ServiceNow’s IT Service Management suite is built specifically for IT operations. While both platforms handle service delivery, they have different data models, workflow patterns, and integration strategies. A direct feature-by-feature migration often misses the opportunity to design workflows that take advantage of ServiceNow’s strengths.

Service Cloud is customizable to handle IT workflows, but you are building IT workflows on a platform designed for a different domain. ServiceNow is designed for IT; many IT workflow patterns are built in. A migration is a good time to step back and ask whether your current workflows are truly optimal or whether they reflect workarounds for Service Cloud’s limitations.

Data Inventory and Assessment

Start by cataloging what you have in Service Cloud: case records and their custom fields, account and contact data, entitlements and service level agreements, knowledge articles, workflows and automation, integrations with other systems. Not all of this maps neatly to ServiceNow. Entitlements in Service Cloud might become support items and contracts in ServiceNow, or they might disappear entirely if your IT organization does not manage them the same way.

Assess data quality. Service Cloud often accumulates custom fields, many used for specific workflows that may no longer be needed. Old data may contain values that no longer align with current business models. During migration planning, you have the opportunity to clean data and rationalize field structures, eliminating technical debt that accumulated over years of Service Cloud customization.

Process Mapping and Workflow Redesign

Many processes you built in Service Cloud exist because the platform required workarounds. For example, if you use custom process builder automations to route cases, ServiceNow’s native workflow engine may eliminate the need for those custom solutions. If you use custom fields to track information that ServiceNow table relationships handle natively, your data structure can become simpler and more maintainable.

Workflow redesign does not mean throwing out everything you learned from years of Service Cloud operation. It means evaluating each workflow: Does ServiceNow have a better way to handle this? Does this workflow reflect how IT should work, or a workaround we built because Service Cloud was not ideal for IT? Would simplifying this workflow reduce maintenance burden without reducing functionality?

Integration patterns often shift. Both platforms have declarative automation and integration tools, so each Service Cloud flow and integration needs a fresh decision about how it is rebuilt, for example in Flow Designer or IntegrationHub. If you integrated Service Cloud with your monitoring system or asset management system, you will re-architect those integrations for ServiceNow’s patterns. This is an opportunity to improve integration quality and reduce custom code if the integrations had workarounds in Service Cloud.

Data Migration Strategy

Case records migrate to incidents with field mapping. You decide which Service Cloud fields map to ServiceNow incident fields and which are dropped. If Service Cloud has custom fields tracking information that does not fit ServiceNow’s model, you need to decide: Does this information still matter? Should we capture it differently in ServiceNow? Do we archive it without migrating?

Accounts and contacts in Service Cloud likely have parallels in ServiceNow, but as configuration items or users, not as the service delivery accounts Service Cloud tracks. You need to decide which contacts become ServiceNow users, which become configuration items, and which are archived. This decision affects how you configure service requests and change management.

Knowledge articles should migrate. If Service Cloud has hundreds of articles, you will filter during migration: keep articles currently used or actively maintained, archive old articles that have been superseded. Migrating everything adds to initial data volume and slows the knowledge search. Archive old articles separately for reference when needed.

Cutover and Parallel Running

If your organization is large enough, parallel running lets you operate in both systems for a limited period, confirming data migrated correctly and workflows function as expected before you shut down Service Cloud. This approach costs more but catches problems before they disrupt operations. Smaller organizations might choose a direct cutover with a short parallel validation.

Plan for people to struggle with interface changes even if workflow logic is identical. ServiceNow’s interface is different from Service Cloud. Some users will prefer the new system quickly; others will need longer to adjust. Providing transition support and being patient with productivity dips for the first week after cutover is part of successful migration.

Phased Rollout and Stabilization

Most organizations cut over one business area at a time. If you support infrastructure, applications, and security incidents, you might cut over infrastructure incidents first, then applications, then security. Each cutover should be small enough that your team can stabilize it within a week before the next cutover. This approach spreads disruption and reduces the risk of overwhelming your team.

Allocate time for stabilization after cutover, sized to the number of open issues. During this period, expect to adjust workflows, fix data issues that were not caught during testing, and optimize integrations. Have your implementation team or knowledge specialists available during this period to address issues before they become operational problems.

Drawing the boundary between IT cases and customer cases comes first

Some organizations run internal IT requests through Salesforce Service Cloud because it was the case tool already in place, and the IT team adopted its queues, entitlements and routing for employee issues. When that IT work moves to ServiceNow, the first question is not how to copy cases across. It is which records belong to the IT service and which belong to the customer relationship that happens to share the same platform. Getting that boundary wrong either moves customer data into an IT tool or leaves IT work stranded in a system that customer teams control.

Deciding which records move and which stay put

The distinction is usually visible in the records themselves. An IT case about a laptop has an employee requester, an asset and a fix. A customer case has an account, a contract and a commercial outcome. Where the two share a case object, the migration needs a rule that separates them before any data moves.

A sequence for separating the two workloads

• Run a report of every case record created by internal users and tag the ones that describe employee technology problems.
• Agree the boundary with the customer service owner in writing, including how a case that starts as customer work and becomes internal is handled.
• Map the IT queues and entitlements to ServiceNow groups and SLA definitions.
• Migrate only the tagged IT records, with their attachments and their activity history where it is needed for audit.
• Decide how the two platforms will exchange a reference when one kind of work depends on the other.

Where the integration boundary usually fails

A common failure is a duplicated customer record created by an IT integration. If an employee who is also a contact of a customer account raises an IT request, a poorly designed integration can create a second person record in one system or the other. Decide which system holds the employee identity, and make the other side a reference. The same care applies to queues. A queue that exists in both platforms will receive work in both, and the team will spend the first month explaining why one request was answered twice.

Entitlements need careful handling too. A Service Cloud entitlement may have expired in the commercial sense while remaining active in the configuration. If those entitlements carry over into ServiceNow SLA logic, new IT cases can start breaching against a commitment that no longer exists. Check each entitlement against the business owner before it is mapped.

When to leave the IT cases where they are

If the organization’s customer service platform is deeply embedded in its employee workflows, and the IT team has built most of its approvals and reporting there, a full move may not be the right first step. A narrower change that moves only the most valuable IT processes can deliver the benefit without disturbing the customer platform. The decision should rest on the service owners’ view of where the work belongs, not on the tool that happens to be newer.

Questions about the case boundary

Should IT and customer cases stay in one platform after the move?

Only if the boundary can be enforced by record type, access rules and reporting. If the two kinds of work share objects and dashboards, expect mixed reporting and accidental exposure of internal detail.

What happens to an IT case that a customer team also needs to see?

Share the outcome, not the internal working notes. A short status reference that the customer team can read is usually enough, and it keeps internal discussion out of their view.

How do we handle agents who work in both platforms?

Give them one clear rule for which platform they use for which work, and remove the other option from their navigation for the work it does not serve.

Integration checkpoints are in the cutover readiness note, and the platform split is described in the workflow boundaries service.