The strategy necessitates a hybrid approach combining SAP Information Lifecycle Management (ILM) for historical data extraction, a temporary MuleSoft integration layer to maintain order flow continuity during the TSA period, and a phased Salesforce implementation prioritizing customer-facing processes before financial closing capabilities. This architecture addresses the zero-downtime constraint by maintaining a temporary bridge between the parent's SAP manufacturing modules and the new Salesforce CRM instance. The requirements specification must document data ownership boundaries, real-time synchronization protocols for in-flight transactions, and independent audit trail preservation mechanisms to satisfy SOX IT General Controls (ITGC) mandates.
Problem Description
A global manufacturing conglomerate was divesting its specialty chemicals division to a private equity firm. The division had operated within the parent's SAP S/4HANA instance for 15 years, sharing customers, vendors, and general ledger accounts with five other divisions. Intercompany sales represented 40% of the division's revenue, with transactions flowing through the parent's centralized treasury function. The Transition Services Agreement allowed only 90 days for complete operational separation, yet the division had 2,500 active customer orders in flight, and the buyer required immediate SOX compliance capability to support their planned IPO within 18 months. The parent company refused to provide ongoing system access beyond the TSA period, and the buyer's Salesforce instance needed to handle both CRM and order-to-cash processes without the deep manufacturing modules available in SAP.
Solution 1: Big Bang Cutover with Full Data Migration
One approach considered was performing a single weekend cutover where all 15 years of historical data would be extracted, cleansed of intercompany transactions, and loaded into Salesforce with a custom data model mimicking SAP structures. This would involve freezing all transactions for 72 hours while the SAP LDS tools carved out the division's data objects.
Pros: Clean separation, no ongoing integration complexity, immediate independence from parent systems.
Cons: Violated the TSA's zero-downtime mandate; Salesforce lacks native support for complex manufacturing BOMs and cost accounting, requiring massive custom development that couldn't be completed in 90 days; risk of data corruption during the 15-year history transformation was unacceptably high given the IPO audit requirements.
Solution 2: Extended TSA with Phased Migration
Another option was negotiating a 12-month extended TSA where the division would continue using SAP for financial closing while gradually migrating customers to Salesforce for new orders only.
Pros: Reduced technical risk, allowed time to build proper Salesforce customizations for manufacturing processes, maintained historical data accessibility in SAP during the transition.
Cons: The buyer's private equity backers refused to accept the liability costs of extended TSA fees ($500K monthly); SOX auditors required the division to demonstrate independent control environments within 90 days, which couldn't be achieved while still using parent's SAP instance; historical intercompany transactions needed restatement as external sales, which couldn't be deferred.
Chosen Solution and Result
The team selected a Dual-Run Architecture using MuleSoft as an intermediary integration bus. For the first 60 days, new customer orders were entered in Salesforce but flowed via MuleSoft into the parent's SAP for fulfillment, while historical data extraction proceeded in parallel using SAP Information Lifecycle Management (ILM) with custom rules to bifurcate intercompany transactions. In days 61-90, order fulfillment shifted to a temporary Microsoft Dynamics 365 instance (already SOX-certified) for manufacturing operations, while Salesforce handled CRM and quoting. Historical data was archived in AWS S3 with Snowflake providing queryable audit trails for the 7-year requirement, rather than attempting to migrate all history into operational Salesforce objects.
This approach satisfied the TSA constraints by maintaining order continuity, achieved SOX readiness by day 85 through the Dynamics 365 controls framework, and cost $2M less than building native Salesforce manufacturing modules. The private equity firm successfully completed their IPO 14 months post-close.
How do you handle the legal and technical ambiguity when the purchase agreement defines the "Business" being sold differently than the SAP technical client structure, resulting in shared customers who buy from both the divested division and retained divisions?
Many candidates assume customer data can simply be copied. The correct approach involves creating a Golden Record strategy where shared customers are replicated in the new environment with masked historical data, while implementing a Master Data Management (MDM) hub using Informatica or Talend to maintain synchronization during the TSA period without violating data privacy clauses. The BA must draft requirements for customer matching algorithms that identify shared entities based on tax ID and address fuzzy matching, then implement data masking rules ensuring the divested entity sees only their transaction history while the parent retains full records.
What specific SOX control requirements must be documented for the interim state when the divested entity uses the parent's SAP system but is technically a separate legal entity?
Candidates often focus only on the target state. During the TSA, the BA must document IT General Controls (ITGC) requirements specifying that the parent maintains SAP GRC (Governance, Risk, and Compliance) access controls while providing the divested entity's auditors read-only access to system logs. Requirements must mandate that all journal entries posted by the divested entity during TSA carry distinct company codes and posting IDs for segregation of duties, and that the parent's SAP Basis team provides automated daily extracts of all transactions affecting the divested entity's balance sheet to a standalone SQL Server repository for independent audit trail preservation.
How do you requirements-model the decomposition of intercompany transactions that were previously internal transfers but must become external sales/purchases post-divestiture?
This requires BPMN process models showing the transformation of internal SAP profit center postings into external EDI transactions. The BA must specify requirements for new pricing master data (transfer pricing becomes external pricing), tax calculation engines (VAT now applies where it didn't before), and accounts receivable/payable standing data creation. Critically, the requirements must include a "Day 1" restatement mechanism where the last 12 months of intercompany transactions are retrospectively reclassified in the Snowflake data warehouse to show the divested entity as an external party, ensuring comparative financial statements for the IPO don't show impossible internal transactions with itself.