Salesforce to SAP Migration: SOX Compliance Guide
This direction typically shows up when a company that has been running quote-to-cash largely inside Salesforce (Revenue Cloud, CPQ, or a heavily customized Sales Cloud implementation) consolidates onto SAP as it scales toward or through an IPO, or when a newly acquired subsidiary gets folded into a parent's SAP-centric financial architecture. It is not a full ERP-to-ERP swap — Salesforce was never your general ledger — but it is a bigger control-migration lift than it looks, because growth-stage companies often built real financial logic (discount approval, revenue recognition triggers, contract lifecycle rules) directly into Salesforce configuration without a formal SOX control framework around it. Moving that logic into SAP means first making it explicit — documenting what the Salesforce configuration was actually enforcing — before you can even begin mapping it to SAP's authorization and workflow model. This guide covers that control-continuity sequence.
Before you start
- ·Full inventory of Salesforce configuration with control implications: approval processes, validation rules, permission sets, and any CPQ/billing logic that determines pricing, discounting, or revenue-recognition triggers
- ·Honest assessment of whether these controls were ever formally documented as part of a SOX control matrix — many growth-stage Salesforce implementations enforce real controls through configuration with no corresponding control narrative, and that gap has to be closed before migration, not carried into SAP
- ·SAP order-to-cash process design workshop with Internal Audit present, using the extracted Salesforce control logic as the requirement source rather than a generic SAP SD implementation template
- ·Revenue recognition analysis confirming which ASC 606-relevant data points (performance obligations, contract terms, variable consideration) were captured in Salesforce and how they will be captured in the new SAP-based process
- ·Cutover calendar agreed with the external auditor, particularly if this migration coincides with IPO readiness or first-year SOX compliance, where control documentation maturity is itself under scrutiny
Migration steps
Extract and document what Salesforce configuration is actually enforcing
Before any SAP design work starts, catalog every approval process, validation rule, and permission-set boundary in Salesforce that has a financial or revenue-recognition consequence. In many growth-stage companies this is the first time this logic has been written down as a formal control rather than existing only as configuration a CPQ administrator understands. Treat this extraction as a control-identification exercise, not a technical inventory — for each item, ask what would go wrong financially if it didn't exist.
Formalize the control matrix before mapping to SAP
Turn the extracted configuration logic into a proper control matrix — control description, owner, frequency, evidence — reviewed and signed off by Internal Audit. If this is happening in the context of IPO readiness or a first SOX compliance cycle, this step is not optional overhead; it is the artifact the auditor will expect to see regardless of which system ultimately hosts the control.
Design SAP SD, pricing, and workflow configuration from the formalized control matrix
Map each control to its SAP mechanism: discount thresholds become release strategies or workflow conditions, contract modification approval becomes an authorization-object restriction plus workflow step, credit management becomes SAP credit management configuration. Do not let the SAP implementation partner default to a standard template — the whole point of the extraction step was to capture what your organization actually needs enforced, and a generic template will not reproduce it.
Design SAP SoD around the same conflict boundaries, validated with GRC or equivalent
Rebuild the SoD logic implied by the Salesforce permission-set boundaries as explicit SAP authorization-object rules, and validate them with SAP GRC Access Control or a comparable SoD tool before go-live. Growth-stage Salesforce orgs frequently have looser SoD boundaries than a mature SAP control design should have — use this migration as the opportunity to tighten them, with Internal Audit's input on where the line should sit.
Preserve revenue-recognition data fidelity through the new process
Confirm every ASC 606-relevant data point captured in the old Salesforce-based process — performance obligations, contract dates, variable consideration — has an equivalent capture point in the new SAP-based order-to-cash flow. A common failure here is losing granularity: Salesforce CPQ line-item detail collapsing into a simpler SAP sales order structure that can no longer support the same revenue allocation logic.
Re-provision access against the new SAP roles, gated by the rebuilt SoD ruleset
Provisioning teams under deadline pressure will try to give each Salesforce user 'equivalent' SAP access to minimize disruption. Require every account activation to pass the rebuilt SoD ruleset first, with conflicts routed to a documented exception decision rather than granted by default.
Run a full control test cycle in SAP before closing the project
Test the complete order-to-cash flow in SAP — quote through contract through revenue recognition — and compare the outcome against the formalized control matrix built in step two. This is the evidence that demonstrates the control environment was not just preserved but actually formalized through the migration, which is often the more important story for an organization moving toward IPO-grade compliance.
Where SOX continuity breaks
- ·Salesforce configuration logic never formally documented as controls before migration, so the SAP implementation has no real requirement source and defaults to a generic template that misses organization-specific rules
- ·Revenue-recognition data granularity lost when CPQ line-item detail collapses into a simpler SAP sales order structure, breaking the ability to reproduce the same ASC 606 allocation logic
- ·SoD boundaries carried forward from a loosely-controlled growth-stage Salesforce org instead of being tightened to match the maturity level expected of a SOX-compliant SAP environment
- ·Migration timed to coincide with IPO readiness without building in time for the control-formalization step, leaving the auditor with a control matrix that was written after the fact to match what got built
- ·Credit management and contract-modification approval treated as pure sales-process configuration in SAP design discussions, missing their SOX relevance because Salesforce administrators — not Internal Audit — drove the requirements
After the cutover
After cutover, run at least one full quarter-end close through the new SAP-based order-to-cash process with Internal Audit reviewing a sample of contracts end-to-end for revenue-recognition accuracy. Use that cycle's results to finalize the ICFR control matrix and narrative — this is often the version that gets tested in the organization's first or next external SOX audit, so treat it as the authoritative baseline rather than a draft.
Common questions
It's common at growth-stage companies and is fixable, but it needs to be addressed before SAP design starts, not discovered during it. Extract and document what the Salesforce configuration was actually enforcing, get it reviewed by Internal Audit, and use that as the requirement source for SAP — rather than letting the SAP implementation invent controls that don't match what the business actually needs.
Book an assessment
Get migration-specific SOX control continuity guidance for Salesforce to SAP.
Book an Assessment →