SAP C4C to V2 Migration: A Strategy That Doesn't Break Your Business

C4C was solid for what it was. It still runs, and SAP still maintains it. But SAP’s new CRM capabilities, including Joule and the new AI agents, are built for Sales Cloud V2 and Service Cloud V2. The gap between what C4C can do and what V2 offers grows with every release.

Since SAP has not set an end date for C4C, you can choose your timing. That makes the how more important than the when.

TL;DR: Moving from C4C to V2 is a reimplementation, not an upgrade: data model, APIs and the extension framework all change. Our five-phase strategy (assessment, integration redesign, parallel build, data migration, adoption) takes 6 to 10 months for a mid-size sales and service organisation. Start with a complete inventory of your C4C setup and a realistic timeline. As of September 2026, SAP has not announced an end-of-maintenance date for C4C, so there is no reason to rush.

Why Isn’t V2 Just an Upgrade?

This is the most important point to understand. SAP built V2 from scratch on SAP BTP. Almost nothing carries over as-is:

• Data model: different. Custom fields, business objects and extensions do not carry over automatically.
• APIs: different. Every integration built on C4C’s OData services needs to be rebuilt against the V2 APIs.
• UI: different. The interface is new, role-based and follows SAP Fiori design.
• Extensibility: different. C4C used key-user tools and the PDI/SDK. V2 uses SAP BTP services. More flexibility, but different skills.

Companies that treat V2 as a version bump run into problems fast. For a feature-by-feature comparison, see SAP Sales Cloud V2 vs. C4C: what actually changed and, for service teams, Service Cloud V2: what’s different.

Why Does Strategy Matter More Than Speed?

When a platform’s future is in question, the instinct is to rush. A rushed migration gives you:

• Broken integrations that nobody mapped before the switch
• Lost business logic buried in undocumented C4C custom code
• Frustrated users, because the new UI looks nothing like the old one
• Budget overruns, because rework costs more than planning

The right approach starts with a full inventory. Every custom field, workflow rule, integration and report gets catalogued and evaluated. Not all of them belong in V2. Some were workarounds that V2 handles in standard. Others are obsolete. The ones that matter deserve a clean rebuild, not a hasty port.

What Does a Solid Migration Look Like?

SAP now provides a Readiness Check Tool (RCT) and a Data Transfer Tool (DTT) for V1-to-V2 moves, and both were extended in the 2508 and 2511 releases (release briefing). The tools help, but they do not replace a strategy. This is the five-phase approach we use.

Phase 1: Assessment and discovery (2 to 4 weeks)

Catalogue everything in the C4C environment: configuration, custom objects, integrations, reports, user roles and workflow automations. Classify each item as:

• Migrate: needed in V2, rebuild it in the new model
• Redesign: needed, but V2 handles it natively (for example, routing rules become skills-based routing)
• Replace: a better option exists in V2 or on BTP
• Retire: no longer needed, or only ever a workaround

This phase prevents the most common source of delay: undocumented customisations discovered mid-migration. If nobody remembers why a workflow rule exists, the team spends days investigating instead of building. 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.

Phase 2: Integration redesign (4 to 6 weeks)

Most C4C integrations need a rebuild, which is also a chance to simplify. SAP provides standard integration content between V2 and S/4HANA, and SAP Integration Suite covers most other scenarios, so you need less custom glue code.

Map every integration point, check whether V2 offers a standard alternative, and replace point-to-point interfaces with event-based integration where V2 publishes the relevant events. Define the target architecture before writing a line of code. If S/4HANA is in your landscape, our guide on how S/4HANA Public Cloud and Sales Cloud V2 work as an integrated stack explains the shared master data, the quote-to-cash flow and what to keep from your C4C integration.

Phase 3: Parallel build (8 to 12 weeks)

Build V2 while C4C stays live. No big-bang cutover. This lets you test properly, validate migration runs and train users before go-live.

Key configuration areas for service teams:

• Case lifecycle states and transitions
• Skills-based routing rules and agent skill profiles
• AI-based case classification, where licensed (load historical cases early)
• Knowledge base migration and restructuring
• SLA definitions and escalation rules

Phase 4: Data migration (4 to 6 weeks)

Accounts, contacts, opportunities, cases and activities move to V2 with SAP’s migration tools. Define mapping rules, run several test migrations with production-scale volumes and fix a clear cutover window. Our step-by-step DTT guide walks through the tool.

If you plan to use AI-based case classification, import historical cases early. The model learns from real cases, not from synthetic test records.

Phase 5: Change management and training (2 to 4 weeks)

The UI change alone justifies dedicated training, but it goes further: workflows, routing, SLA visibility and AI features all work differently in V2. Bring key users into UAT, train hands-on instead of with slide decks, and plan 2 to 4 weeks of stabilisation after go-live.

What Does Migration Work Teach Us?

The same patterns show up whenever we plan or review a move from C4C to V2.

Document everything in C4C before you start. The biggest delays come from undocumented customisations discovered mid-migration.

Don’t migrate technical debt. If a C4C workaround was always ugly, do not rebuild it in V2. V2 covers many old pain points in standard: case hierarchies, skills-based routing, SLA automation. Use the migration to clean up.

Plan generous time for integrations. Every C4C API endpoint changes in V2. Ten integrations mean ten rebuilds, and the budget should say so.

Invest in adoption early. The best system fails if people resist it. Start change management on day one. For service teams, the shift is about new skills on the agent desktop, not only new screens.

Test with real data. Synthetic test data hides problems. Run test migrations with production-scale volumes to catch issues before go-live.

Why Does Your Choice of Partner Matter?

A C4C-to-V2 migration is not a standard project. A partner who only knows V2 misses the quirks of your C4C setup. A partner who only knows C4C cannot design the V2 target state properly. You need a team that understands both the system you are leaving and the one you are moving to, and, if V2 has to talk to your ERP, one that knows S/4HANA too.

What to look for:

• Hands-on C4C experience: the old data model, API quirks and extension patterns
• Delivered V2 projects: live V2 environments, not only SAP training
• Integration skills across S/4HANA, SAP BTP and third-party systems
• A repeatable method instead of improvisation
• Change management, not only technical delivery

At Spadoom, the same team covers Sales and Service Cloud V2, the BTP extensions and the S/4HANA side of the integration. For a wider view of how to judge partners, see how to choose an SAP CX partner and our overview of SAP CX consultancies in Switzerland.

Why Not Wait Another Quarter?

Waiting is a legitimate option, since C4C has no announced end date. But it has costs:

• V2 keeps gaining capabilities (AI case classification, Joule, Joule agents) that C4C will not get.
• SAP Jam Collaboration, part of the V1 bundle, will no longer be accessible from 1 January 2027 (release briefing). If you use it, you need a replacement anyway.
• C4C technical debt keeps growing, which makes the eventual migration bigger.

Rushing is still worse than waiting. A clear strategy, a thorough assessment and realistic timelines turn the migration from a risk into an improvement. Check the SAP Roadmap Explorer and the Service Cloud V2 documentation for the features you rely on, and use our V1-to-V2 comparison to size the move.

For a detailed walkthrough for service teams, see our Service Cloud V2 migration guide. If you want a second opinion on your plan, talk to our team.

FAQ

How long does a C4C-to-V2 migration take?

For a combined sales and service migration with 50 to 200 users, plan 6 to 10 months across five phases. Smaller environments can finish in 4 to 6 months; heavily customised setups take 10 to 14 months. Integration rework is the phase that most often runs over, so budget generously.

Can we run C4C and V2 in parallel?

Yes, and you should. Building V2 while C4C stays live lets you test, validate the data migration and train users before cutover. Plan at least 8 to 12 weeks of overlap during the build phase.

What happens to our C4C integrations?

Each one needs review and most need a rebuild, because V2’s API endpoints and data model differ. SAP’s standard integration content for S/4HANA and SAP Integration Suite often makes the rebuilt integrations simpler than the originals, especially when you replace point-to-point interfaces with event-based ones.

Do we need new skills for V2?

Yes. V2 extensions run on SAP BTP with CAP, Node.js or Java instead of C4C’s PDI/SDK. If your team has no BTP experience, plan training or work with a partner who has delivered V2 extensions.

Is there an official C4C end-of-life date?

No. As of September 2026, SAP has not announced an end-of-maintenance date for C4C, and V1 still receives regular releases. New innovation such as Joule agents goes into V2, and SAP Jam Collaboration, part of the V1 bundle, will no longer be accessible from 1 January 2027. Plan the move on your own schedule, not under deadline pressure.