Moving Your Service Desk From C4C to Service Cloud V2: Cases, SLAs and Integrations

SAP Service Cloud V2 is not an upgrade from C4C. It is a reimplementation: different data model, different APIs, different user interface, different extension framework. Teams that treat it as a version bump usually find out during data migration, when mappings that “should just work” don’t. If you want a fixed-price first step, our V1 to V2 migration readiness assessment checks your landscape in 3 days for CHF 7’500, credited against the V2 implementation.

For a mid-size organisation (50 to 200 service agents), expect 6 to 10 months from assessment to go-live. This post describes the five phases we use for service desks specifically. For the business case behind the move, read our C4C to V2 migration strategy; for the product itself, see the SAP Service Cloud V2 solution page.

TL;DR: Moving from C4C to Service Cloud V2 is a reimplementation. Plan 6 to 10 months for a mid-size service organisation, in five phases: assessment, integration redesign, parallel build, data migration, and training with go-live. Integration rework and agent training are where timelines slip, so start both early.

What Actually Changes in V2?

SAP built Service Cloud V2 on a new cloud-native architecture rather than evolving the C4C code base. SAP documents the new product separately in the SAP Service Cloud Version 2 help portal, next to the existing SAP Cloud for Customer documentation. For a migration, five differences matter:

Technical platform. V2 runs on a different platform with its own administration, monitoring and deployment model. Custom logic runs side by side on SAP BTP.

Data model. Flat ticket records become structured case entities with lifecycle states, parent-child hierarchies and built-in SLA tracking. Custom fields and custom business objects do not transfer automatically.

APIs. V2 has its own API-first design. Every integration built against C4C’s OData services needs to be rebuilt against the V2 APIs.

User interface. Completely new and role-based. Agents need training, not just a changelog.

Extensibility. C4C’s PDI/SDK extensions have no equivalent in V2; their logic moves to BTP services (Node.js, Java, CAP). More flexible, but it requires different skills. For a feature-by-feature comparison, see SAP Service Cloud V2 vs V1: What Changed.

What’s the 5-Step Migration Process?

Step 1: Assessment and inventory (2 to 4 weeks)

Catalogue everything in your C4C environment: configuration, custom fields, business objects, integrations, reports, workflow rules and user roles. Then classify each item.

Migrate it if you need it in V2 and will rebuild it in the new model. Redesign it if you need it but V2 covers it natively (routing rules, for example, become skills-based routing). Retire it if it is no longer needed or only existed as a workaround.

This phase prevents the most common source of delay: undocumented customisations surfacing halfway through the project. If nobody remembers why a workflow rule exists, the team spends days finding out. On projects where the assessment was rushed, this is exactly what happened.

Step 2: Integration redesign (4 to 6 weeks)

Most C4C integrations need a full rebuild. The upside is that V2 comes with SAP-delivered integration content for S/4HANA, Sales Cloud V2, Commerce Cloud and other SAP products, so the target design is often simpler than what you have today.

Map every integration point, check the V2-native alternatives and define the target architecture before anyone writes code. It is also the moment to replace point-to-point connections with event-based integration via SAP Integration Suite, which is easier to monitor and maintain. If S/4HANA Public Cloud is part of your landscape, Service Cloud V2 + S/4HANA Public Cloud: From Service Ticket to ERP Order shows the target process.

Step 3: Parallel build (8 to 12 weeks)

Build V2 while C4C stays live. No big-bang cutover.

The key configuration areas are case lifecycle states and transitions, skills-based routing rules and agent skill profiles, AI case classification (which needs historical cases), knowledge base migration and restructuring, and SLA definitions with escalation rules.

This lets you test, validate migration scripts and train users before go-live, while your agents keep working in C4C.

Step 4: Data migration (4 to 6 weeks)

Migrate historical cases, accounts, contacts and activities with SAP’s migration tooling. Define mapping rules for the new data model, run several test migrations with production-scale volumes and agree a clear cutover window. The mechanics of the Data Transfer Tool are described in our step-by-step DTT migration guide.

One detail is easy to miss: AI-based case classification learns from real cases. Load historical cases early so the model has data before go-live; otherwise you launch without one of the main reasons for moving to V2.

Step 5: Training and go-live (2 to 4 weeks)

The new interface alone needs proper training, and the workflow changes go deeper: routing, SLA visibility, knowledge access and AI-assisted features all work differently from what your agents know.

Involve key users in acceptance testing, train hands-on rather than with slide decks, and plan a 2 to 4 week stabilisation period with adoption support after go-live. Skipping this step is the fastest way to lose your agents’ goodwill for the new system.

What Are the Most Common Migration Pitfalls?

The same patterns come up on almost every migration.

Undocumented C4C customisations. Workflow rules, calculated fields and integration mappings nobody wrote down cause the biggest delays. Use the assessment phase to document all of them, including the workflow rule a predecessor set up years ago.

Treating V2 as a lift-and-shift. Teams that copy their C4C setup one to one miss the chance to simplify. Several C4C workarounds are unnecessary in V2 because case hierarchies and skills-based routing are standard.

Underestimating integration rework. Every C4C interface changes. Ten integrations mean ten rebuilds, and they tend to take longer than estimated.

Skipping change management. The interface needs training, and so do the changed workflows, routing, SLA visibility and AI features. Agents without training fall back to manual workarounds within days.

Ignoring AI data prerequisites. Case classification needs historical data. Load it late and you go live without AI.

Why Migrate Now Rather Than Later?

SAP’s innovation for service is in V2. As of September 2026, SAP has not announced an end-of-maintenance date for C4C, and V1 still receives releases, but new capabilities such as Joule agents target V2. Check the SAP Roadmap Explorer for the current plans. Every quarter on C4C adds customisations and integrations you will have to migrate later, and widens the gap to V2’s AI features and the BTP extension model.

Rushing is still worse than waiting. A clear strategy, a thorough assessment and a realistic timeline are what turn the migration into an improvement rather than a risk. If you are still deciding, our V1-to-V2 migration wizard gives a first estimate, and the V1 vs V2 migration comparison covers the decision in more depth. When you are ready to plan, talk to our team.

FAQ

Is Service Cloud V2 an upgrade from V1?

No. Service Cloud V2 is a new product with its own data model, APIs, user interface and extension model. Custom fields, integrations and extensions from C4C (V1) do not carry over; they have to be rebuilt or redesigned in V2.

How long does a C4C to Service Cloud V2 migration take?

For a mid-size organisation (50 to 200 service agents, moderate integration complexity) plan 6 to 10 months. Smaller environments under 50 agents can finish in 4 to 6 months; heavily customised landscapes take 10 to 14 months.

Can we run V1 and V2 in parallel during migration?

Yes, and you should. Building V2 while C4C stays live lets you test, rehearse the data migration and train agents before cutover. We recommend a parallel period of at least 8 to 12 weeks.

What happens to our C4C integrations?

Every C4C integration needs a review and most need a rebuild, because V2’s APIs and data model are different. V2’s standard integration content for S/4HANA and other SAP products often makes the target design simpler than the C4C original.

Do we need BTP skills for V2?

Yes. Custom logic for V2 runs side by side on SAP BTP (Node.js, Java or SAP CAP) instead of C4C’s PDI/SDK. If your team has no BTP experience, plan training or work with a partner that has delivered V2 extensions.