Rolling Out S/4HANA Public Cloud and Sales Cloud V2 Together: Sequencing, Timeline, Pitfalls

Should you implement S/4HANA Public Cloud and SAP Sales Cloud V2 at the same time?

That’s one of the most common questions we hear from DACH companies modernising their SAP landscape. The honest answer: it depends on which problem is more urgent, and whether your organisation has the programme management capacity to run both.

Done well, a joint rollout gives you a clean shared data model from day one — one Business Partner record, one product catalogue, one order flow. Done badly, two parallel projects compete for the same IT bandwidth, the same key users, and the same change management attention. Something breaks, or both land late.

This post lays out the three sequencing options, what a realistic combined timeline looks like, where the two project teams must stay in sync, and the pitfalls we’ve seen more than once.

Should you implement S/4HANA Public Cloud and Sales Cloud V2 at the same time?

The starting point is being honest about your constraints.

Running two major SAP implementations in parallel is ambitious. Both systems touch your core business processes. Both require key user time for workshops, testing, and training. Both need integration work on BTP. If your IT team or consulting budget is stretched, sequencing is safer.

But there’s a real argument for parallel delivery. The Business Partner model is shared between S/4HANA Public Cloud and SAP Sales Cloud V2. If you implement CRM first without ERP, you’ll set up a temporary integration to your existing ERP — and then have to re-do parts of it when S/4HANA arrives. That’s rework you can avoid with better sequencing.

The right answer depends on three things: which system your business needs more urgently, what your change management capacity looks like, and whether you have a partner who can hold the integration layer accountable across both streams.

Three sequencing options

ERP-first, then CRM

This is the safest default. S/4HANA Public Cloud goes live first, establishing the Business Partner master data model, the product catalogue, and the financial processes. Once the ERP is stable — typically 3 to 6 months post go-live — the Sales Cloud V2 project starts with clean source data to integrate against.

The trade-off: your sales team waits. If your CRM situation is critical — manual processes, data in spreadsheets, no pipeline visibility — a 9- to 12-month wait for a better sales tool is painful.

What this option buys you: Sales Cloud V2 goes live with real ERP data from day one. No temporary connectors to retire. No data migration from an interim CRM state. The integration work is done once, correctly.

CX-first, then ERP

Less common, but it makes sense when the sales process is the primary pain point and the ERP is already stable enough to leave alone for now.

SAP Sales Cloud V2 goes live against the existing ERP — whether that’s ECC, S/4HANA on-premise, or something else. The integration is built for that ERP. Later, when S/4HANA Public Cloud arrives, the integration is rebuilt against the new ERP endpoints.

The trade-off: you accept double integration work. The first integration is thrown away when the ERP changes. That’s real cost and rework — but if getting a modern CRM to the sales team in the next quarter is the priority, it can be the right call.

One risk to flag: if your existing ERP has messy master data — inconsistent Business Partner records, duplicate accounts, outdated pricing — you’ll import that mess into Sales Cloud. And then clean it up again before the S/4HANA migration. Better to clean once, in the ERP migration, and start Sales Cloud fresh.

Parallel delivery

Both projects run simultaneously with a shared integration work stream. This compresses the overall timeline but adds significant coordination overhead.

For this to work you need: a dedicated programme manager who owns the cross-stream dependencies, a clear integration owner on BTP, and joint steering that can resolve priority conflicts when both projects want the same key users at the same time.

We’ve seen parallel delivery work well when the two workstreams are genuinely separate in terms of team and scope — ERP team owns finance and logistics, CX team owns sales process — and they only need to converge on the integration layer and master data governance. Where it falls apart is when the same three people are expected to be key users on both projects simultaneously.

A realistic combined timeline

These are separate estimates, not a single combined figure.

S/4HANA Public Cloud greenfield implementations for SMEs with a clean process scope — no heavy customisation, standard processes — typically run 6 to 9 months from kickoff to go-live. That’s the documented range for standard greenfield rollouts. Complex scope, multi-country, or significant data migration extends that.

SAP Sales Cloud V2 mid-market implementations — typically 50 to 200 users, one country, standard CRM processes — run 10 to 16 weeks. Our median across completed Sales Cloud V2 projects is 14 weeks from kickoff to go-live. Smaller teams with tighter scope land faster. Enterprise deployments with complex ERP integrations take longer.

For a combined ERP-first programme: the ERP lands at month 6 to 9, CX starts 1 to 2 months before ERP go-live (beginning integration design work early), and Sales Cloud V2 goes live at roughly month 10 to 15. That’s the realistic end-to-end range for a sequential rollout.

Parallel delivery shortens the total programme — both systems can target the same quarter — but not by as much as people expect. The integration layer still needs to be built, tested, and stabilised regardless of whether the two projects run in sequence or in parallel.

For detailed guidance on the CX side of this, our SAP Sales Cloud V2 implementation guide covers the full project phases, team structure, and cost breakdown.

Where the two project teams must sync

Even in a sequential rollout, the two teams can’t operate in complete isolation. There are four areas where they must coordinate.

Business Partner model and master data governance. The S/4HANA project defines the Business Partner record structure — fields, segments, roles. Sales Cloud V2 consumes that structure. If the CX team isn’t in the room during the ERP master data design, they’ll discover at integration time that the fields they need don’t exist or have different names. Fix: include a CX representative in every ERP master data workshop.

Product catalogue and pricing. Sales Cloud V2 pulls pricing from S/4HANA. The ERP project team must finalise the pricing condition types and catalogue structure before the CX integration can be built. A common mistake: ERP team locks the pricing model two months after the CX integration has already been designed for a different structure.

User management and authorisation. Both systems will use the same identity provider, typically SAP Identity Authentication Service. User provisioning, role assignment, and SSO must be designed once and work for both systems. Don’t let each project solve this independently.

Change management timing. Key users cannot attend S/4HANA training in month 7 and Sales Cloud V2 training in month 8 without burnout. Sequence the training programmes deliberately, with enough breathing room between go-lives for users to stabilise on the first system before learning the second.

Pitfalls we’ve seen and how to avoid them

Two steering committees with no shared escalation path. The ERP project has its own steering group. The CX project has its own. When a cross-stream decision needs to be made — who owns the integration BTP tenant? who funds the shared middleware? — there’s no forum to make it. The decision stalls for weeks. Fix: establish a joint programme steering from day one, even if it only meets monthly.

Integration scope defined too late. Both projects assume the other team will handle the integration. At go-live minus six weeks, nobody has started building the order flow from Sales Cloud to S/4HANA. Fix: the integration scope, ownership, and budget must be agreed before either project starts the Realize phase.

Dirty ERP data imported into Sales Cloud. The ERP data migration cleans customer records. But the CRM integration is built from the old ERP data, not the cleaned ERP data, because the timelines aren’t aligned. Sales Cloud goes live with 14,000 duplicate accounts. Fix: the CRM data migration must source from the post-cleaned ERP state, which means sequencing data cleansing before the CRM go-live, not in parallel.

Change fatigue. Finance users absorb a new ERP. Two months later, the same organisation is asked to adopt a new CRM. Adoption suffers on both. Fix: build a realistic change management capacity plan before signing off on the programme timeline. The S/4HANA Public Cloud and Sales Cloud V2 integrated stack is worth nothing if users revert to spreadsheets.

Underestimating BTP footprint. Both projects will use BTP — Integration Suite, Identity Authentication, possibly Build. If each project procures its own BTP instances, you end up with duplicated tenants, double costs, and an integration architecture that can’t share components. Fix: define the BTP strategy as a programme-level decision, not a project-level one.

The technical integration between SAP S/4HANA Public Cloud and Sales Cloud V2 is well-documented and achievable. The hard part isn’t the technology. It’s running two major change programmes in the same organisation, with the same people, without one undermining the other.

Get the sequencing right, establish clear ownership at the integration layer, and give your organisation enough time to absorb each system before the next one lands. That’s what separates a clean combined rollout from a long, expensive recovery project.

Want to talk through the sequencing for your specific situation? Let us know the details — no pitch deck, just a conversation.