From “Sold-to/Ship-to/Bill-to” in Legacy Systems to Business Partner in SAP: A Real-World Migration Perspective
- ankitasondhiya
- Aug 8
- 3 min read
If you’ve ever moved house, you know it’s not just about packing boxes — it’s about deciding what to keep, what to discard, and how to arrange things in the new space.Migrating from Microsoft Dynamics AX to SAP S/4HANA is a lot like that.
One of the most noticeable — and often underestimated — changes you’ll face is moving from AX’s way of storing Sold-to, Ship-to, and Bill-to details to SAP’s Business Partner (BP) model.
And make no mistake — this isn’t just a name change. It’s a fundamental rethinking of how you store, connect, and manage customer and vendor relationships.
How SAP S/4HANA Sees the World
In SAP’s world, there’s no separate “customer file” here and “vendor file” there.Instead, everything revolves around the Business Partner record — a single, central master that can represent a customer, a supplier, or both.
Within that BP, you assign roles to define its purpose:
FLCU01 – Customer (Sales Area data)
FLCU00 – Customer (Financial Accounting data)
FLVN01 – Supplier (Purchasing Organization data)
FLVN00 – Supplier (Financial Accounting data)
This unified approach means:
Less duplication
Cleaner master data
Easier reporting across sales, finance, and procurement
Think of it as going from having three separate contact lists on your phone to having one contact card with all their phone numbers, emails, and addresses neatly linked.
How Microsoft Dynamics AX/ Legacy Does It
AX takes a different approach.
Here, Sold-to Party, Ship-to Party, and Bill-to Party are often stored:
In separate tables, or
As additional addresses under a customer or vendor record
For example:
Sold-to Party → Main customer account (used for sales orders)
Ship-to Party → Additional delivery address under the customer
Bill-to Party → Another additional address — but not always clearly labeled
Example Let’s say ABC Manufacturing places an order:
Products are sold to their headquarters in Chicago (Sold-to)
Shipped to a warehouse in Dallas (Ship-to)
Invoiced to their finance office in New York (Bill-to)
In AX, all of these might just live as extra addresses for “ABC Manufacturing” — with no explicit role tags. That works… until you try to migrate and realize SAP expects those to be separate BP roles with defined relationships.
Where the Migration Gets Tricky
Migrating from AX to SAP BP isn’t simply a “copy and paste” job — it’s more like untangling a box of old charger cables before you can neatly store them in a new organizer.
Here’s why:
1. Address Role Ambiguity
AX doesn’t always clearly label whether an additional address is a Ship-to or Bill-to. This means you’ll have to apply business rules or manual checks to assign the right role in SAP.
2. Duplicate Entity Conflicts
What if your Bill-to address in AX is already a supplier in SAP? Merging these into one BP without creating data conflicts requires careful mapping.
3. Relationship Building Complexity
In SAP, you can explicitly say:“Sold-to BP 1001 is linked to Bill-to BP 1002.”In AX, these links are often implied rather than recorded — making it harder to replicate in the BP model.
4. The AX “Additional Address” Challenge
In AX, it’s common for both Ship-to and Bill-to to be stored under the main customer as just extra addresses.If those addresses also exist as independent customers or suppliers in another context, it gets messy — you now have to decide whether to merge them or keep them separate in SAP.
5. Data Enrichment Gaps
SAP wants more — tax IDs, BP groups, role-specific data. Many AX records simply don’t have these details, meaning data enrichment is a must before migration.
Best Practices for a Smooth Transition
Start with Address Cleansing → Tag each address in AX as Ship-to, Bill-to, or other before starting BP mapping.
Map Relationships Early → Document how AX entities will translate to BP roles and links.
Involve the Business → Sales, finance, and logistics teams often know the “unwritten rules” behind addresses.
Test in Iterations → Don’t wait until go-live to find relationship conflicts — test with sample data early.
Pro tip: Treat relationship mapping as a project of its own — not just part of data migration.
Final Thoughts
Moving from AX’s address-based structure to SAP’s Business Partner model is more than just a database migration — it’s a data governance transformation.Done right, it brings cleaner relationships, better reporting, and smoother cross-department workflows.
But rushed or overlooked? You’ll spend months untangling duplicated BPs and fixing broken relationships.
Want to fast-track your BP strategy? Read Part 1 here:
