Service-Desk von C4C zu Service Cloud V2 migrieren: Fälle, SLAs und Schnittstellen

SAP Service Cloud V2 ist kein Upgrade von C4C, sondern eine Neueinführung: anderes Datenmodell, andere APIs, andere Oberfläche, anderes Erweiterungs-Framework. Wer den Wechsel wie ein Versions-Update behandelt, merkt das meist bei der Datenmigration, wenn Zuordnungen, die «einfach funktionieren sollten», eben nicht funktionieren. Wer mit einem Festpreis beginnen will: Unser Readiness Assessment für die Migration von V1 zu V2 prüft Ihre Landschaft in 3 Tagen für CHF 7’500, angerechnet an die V2-Einführung.

Für eine mittelgrosse Organisation (50 bis 200 Service-Agenten) sollten Sie 6 bis 10 Monate von der Analyse bis zum Go-live rechnen. Dieser Beitrag beschreibt die fünf Phasen, die wir speziell für Service-Desks nutzen. Das Geschäftsargument für den Wechsel finden Sie in unserer Strategie für die Migration von C4C zu V2, das Produkt selbst auf der Lösungsseite SAP Service Cloud V2.

Kurzfassung: Der Wechsel von C4C zu Service Cloud V2 ist eine Neueinführung. Planen Sie für eine mittelgrosse Service-Organisation 6 bis 10 Monate in fünf Phasen: Analyse, Neukonzeption der Integration, paralleler Aufbau, Datenmigration sowie Schulung und Go-live. Zeitpläne verrutschen vor allem bei der Integration und der Schulung der Agenten, also beginnen Sie mit beidem früh.

Was sich in V2 wirklich ändert

SAP hat Service Cloud V2 auf einer neuen Cloud-nativen Architektur gebaut, statt die C4C-Codebasis weiterzuentwickeln. SAP dokumentiert das neue Produkt eigenständig im Hilfeportal zu SAP Service Cloud Version 2, neben der bestehenden Dokumentation zu SAP Cloud for Customer. Für die Migration zählen fünf Unterschiede:

Technische Plattform. V2 läuft auf einer anderen Plattform mit eigener Administration, eigenem Monitoring und eigenem Deployment-Modell. Eigene Logik läuft nebenan auf SAP BTP.

Datenmodell. Aus flachen Ticketdatensätzen werden strukturierte Fälle mit Lebenszyklusstatus, Hierarchien und eingebauter SLA-Überwachung. Eigene Felder und eigene Business-Objekte werden nicht automatisch übernommen.

APIs. V2 hat ein eigenes, API-zentriertes Design. Jede Schnittstelle, die auf den OData-Services von C4C aufbaut, muss gegen die V2-APIs neu gebaut werden.

Oberfläche. Komplett neu und rollenbasiert. Die Agenten brauchen eine Schulung, nicht nur eine Liste der Änderungen.

Erweiterbarkeit. Für PDI/SDK-Erweiterungen aus C4C gibt es in V2 kein Gegenstück; ihre Logik wandert in BTP-Services (Node.js, Java, CAP). Das ist flexibler, verlangt aber andere Fähigkeiten. Einen Vergleich Funktion für Funktion finden Sie in SAP Service Cloud V2 vs. V1: Was sich geändert hat.

Wie läuft die Migration in fünf Schritten ab?

Schritt 1: Analyse und Inventar (2 bis 4 Wochen)

Erfassen Sie alles, was in Ihrer C4C-Umgebung steckt: Konfiguration, eigene Felder, Business-Objekte, Schnittstellen, Berichte, Workflow-Regeln und Benutzerrollen. Danach ordnen Sie jedes Element ein.

Migrieren, wenn Sie es in V2 brauchen und im neuen Modell nachbauen. Neu konzipieren, wenn Sie es brauchen, V2 es aber standardmässig abdeckt (Routing-Regeln werden zum Beispiel zu kompetenzbasiertem Routing). Stilllegen, wenn es nicht mehr gebraucht wird oder nur ein Workaround war.

Diese Phase verhindert die häufigste Verzögerung: undokumentierte Anpassungen, die mitten im Projekt auftauchen. Weiss niemand mehr, wozu eine Workflow-Regel existiert, sucht das Team tagelang. In Projekten mit einer überhasteten Analyse ist genau das passiert.

Schritt 2: Neukonzeption der Integration (4 bis 6 Wochen)

Die meisten C4C-Schnittstellen müssen komplett neu gebaut werden. Der Vorteil: V2 bringt SAP-Integrationsinhalte für S/4HANA, Sales Cloud V2, Commerce Cloud und weitere SAP-Produkte mit, sodass das Zieldesign oft einfacher wird als der heutige Stand.

Erfassen Sie jeden Integrationspunkt, prüfen Sie die V2-eigenen Alternativen und legen Sie die Zielarchitektur fest, bevor jemand Code schreibt. Es ist auch der richtige Moment, Punkt-zu-Punkt-Verbindungen durch eine ereignisbasierte Integration über die SAP Integration Suite zu ersetzen, die sich leichter überwachen und warten lässt. Gehört S/4HANA Public Cloud zu Ihrer Landschaft, zeigt SAP Service Cloud V2 + S/4HANA Public Cloud: vom Service-Ticket zum ERP-Auftrag den Zielprozess.

Schritt 3: Paralleler Aufbau (8 bis 12 Wochen)

Bauen Sie V2 auf, während C4C produktiv bleibt. Keine Umstellung im Big-Bang.

Die wichtigsten Konfigurationsbereiche sind Lebenszyklusstatus und Übergänge der Fälle, kompetenzbasierte Routing-Regeln und Skill-Profile der Agenten, die KI-gestützte Fallklassifizierung (die historische Fälle braucht), die Migration und Neustrukturierung der Wissensdatenbank sowie SLA-Definitionen mit Eskalationsregeln.

So können Sie testen, Migrationsskripte validieren und Anwender vor dem Go-live schulen, während Ihre Agenten weiter in C4C arbeiten.

Schritt 4: Datenmigration (4 bis 6 Wochen)

Migrieren Sie historische Fälle, Accounts, Kontakte und Aktivitäten mit den Migrationswerkzeugen von SAP. Definieren Sie Zuordnungsregeln für das neue Datenmodell, führen Sie mehrere Testmigrationen mit produktionsnahen Volumen durch und vereinbaren Sie ein klares Umstellungsfenster. Wie das Data Transfer Tool funktioniert, beschreibt unser Schritt-für-Schritt-Leitfaden zur DTT-Migration.

Ein Detail geht leicht unter: Die KI-gestützte Fallklassifizierung lernt aus echten Fällen. Laden Sie historische Fälle früh, damit das Modell vor dem Go-live Daten hat. Sonst starten Sie ohne einen der Hauptgründe für den Wechsel zu V2.

Schritt 5: Schulung und Go-live (2 bis 4 Wochen)

Schon die neue Oberfläche verlangt eine richtige Schulung, und die Änderungen an den Abläufen gehen tiefer: Routing, SLA-Sicht, Wissenszugriff und KI-Funktionen funktionieren anders, als Ihre Agenten es gewohnt sind.

Beziehen Sie Key-User in die Abnahmetests ein, schulen Sie praktisch statt mit Foliensätzen und planen Sie nach dem Go-live 2 bis 4 Wochen Stabilisierung mit Begleitung ein. Wer diesen Schritt auslässt, verspielt am schnellsten das Wohlwollen der Agenten gegenüber dem neuen System.

Was sind die häufigsten Stolpersteine?

Bei fast jeder Migration zeigen sich dieselben Muster.

Undokumentierte C4C-Anpassungen. Workflow-Regeln, berechnete Felder und Schnittstellenzuordnungen, die nie aufgeschrieben wurden, verursachen die grössten Verzögerungen. Nutzen Sie die Analysephase, um alles zu dokumentieren, auch die Workflow-Regel, die ein Vorgänger vor Jahren eingerichtet hat.

V2 als Eins-zu-eins-Umzug behandeln. Wer sein C4C-Setup unverändert nachbaut, verpasst die Chance zur Vereinfachung. Mehrere C4C-Workarounds sind in V2 überflüssig, weil Fallhierarchien und kompetenzbasiertes Routing zum Standard gehören.

Den Integrationsaufwand unterschätzen. Jede C4C-Schnittstelle ändert sich. Zehn Schnittstellen bedeuten zehn Neubauten, und die dauern in der Regel länger als geschätzt.

Change-Management auslassen. Die Oberfläche braucht eine Schulung, ebenso die geänderten Abläufe, das Routing, die SLA-Sicht und die KI-Funktionen. Ungeschulte Agenten greifen innert Tagen wieder zu manuellen Umwegen.

Die Datenvoraussetzungen für KI ignorieren. Die Fallklassifizierung braucht historische Daten. Wer sie spät lädt, geht ohne KI live.

Warum jetzt migrieren und nicht später?

Die Innovation von SAP im Service findet in V2 statt. Stand September 2026 hat SAP für C4C kein Wartungsende angekündigt, und V1 erhält weiterhin Releases, doch neue Funktionen wie Joule-Agenten zielen auf V2. Die aktuellen Pläne zeigt der SAP Roadmap Explorer. Jedes Quartal auf C4C bringt zusätzliche Anpassungen und Schnittstellen, die Sie später migrieren müssen, und vergrössert den Abstand zu den KI-Funktionen und dem BTP-Erweiterungsmodell von V2.

Überstürzen ist trotzdem schlimmer als Abwarten. Eine klare Strategie, eine gründliche Analyse und ein realistischer Zeitplan machen die Migration zur Verbesserung statt zum Risiko. Wenn Sie noch entscheiden, liefert unser V1-zu-V2-Migrationsassistent eine erste Schätzung, und der Vergleich V1 vs. V2 vertieft die Entscheidung. Wenn Sie planen möchten, sprechen Sie mit unserem Team.

Häufig gestellte Fragen

Ist Service Cloud V2 ein Upgrade von V1?

Nein. Service Cloud V2 ist ein neues Produkt mit eigenem Datenmodell, eigenen APIs, eigener Oberfläche und eigenem Erweiterungsmodell. Eigene Felder, Schnittstellen und Erweiterungen aus C4C (V1) werden nicht übernommen, sondern in V2 neu gebaut oder neu konzipiert.

Wie lange dauert eine Migration von C4C zu Service Cloud V2?

Für eine mittelgrosse Organisation (50 bis 200 Service-Agenten, mittlere Integrationskomplexität) sollten Sie 6 bis 10 Monate einplanen. Kleinere Umgebungen unter 50 Agenten schaffen es in 4 bis 6 Monaten; stark angepasste Landschaften brauchen 10 bis 14 Monate.

Können wir V1 und V2 während der Migration parallel betreiben?

Ja, und das sollten Sie auch. Wenn Sie V2 aufbauen, während C4C produktiv bleibt, können Sie testen, die Datenmigration proben und die Agenten vor der Umstellung schulen. Wir empfehlen eine Parallelphase von mindestens 8 bis 12 Wochen.

Was passiert mit unseren C4C-Schnittstellen?

Jede C4C-Schnittstelle muss überprüft und die meisten müssen neu gebaut werden, weil APIs und Datenmodell von V2 anders sind. Der SAP-Standardintegrationsinhalt für S/4HANA und andere SAP-Produkte macht das Zieldesign oft einfacher als das C4C-Original.

Brauchen wir BTP-Know-how für V2?

Ja. Eigene Logik für V2 läuft nebenan auf SAP BTP (Node.js, Java oder SAP CAP) statt im PDI/SDK von C4C. Fehlt Ihrem Team BTP-Erfahrung, planen Sie Schulungen ein oder arbeiten Sie mit einem Partner, der V2-Erweiterungen bereits umgesetzt hat.