SAP will phase out the NEO Integration Platform on May 16, 2025. All Customers of SAP Business Network for Logistics (BN4L) must transition to the Multi-Cloud platform to ensure business continuity. This document consolidates frequently asked questions from real-world projects and the official SAP migration guides.
Q: What happens to my Freight Order (FO) or Freight Settlement Document (FSD) created via NEO if they remain open after May 16, 2025?
Freight Orders and Freight Settlement documents that were originally created and sent via the NEO integration platform will continue to work after May 16, 2025, as long as the NEO connection stays untouched and NOT deleted.
- Follow-up messages (e.g. confirmation, invoice) for those documents will continue to be routed via Neo.
- SAP will maintain backward compatibility to ensure that messages related to Neo-originated documents are processed successfully.
- Important: Do not delete or modify your NEO connections in the System Connections app. These connections are still required for processing existing documents even after the official NEO deprecation date.
Q: After the Shipper migrates from NEO to Multi-Cloud, how are Carrier responses (Order Confirmation, Invoice) routed for Freight Orders created before and after the migration?
The document routing logic depends entirely on where the FO (Freight Order) was originally sent from. Even if the Shipper and/or Carrier migrate, the platform used to send the original FO determines the message return path.
Below are five common scenarios that illustrate how documents are routed:
Scenario 1:
The Shipper sends a Freight Order (FO) from NEO, then the Shipper migrates their Inbound connections to Multi-Cloud, while the Carrier remains on NEO.
Result:
- Carrier follow-up responses (e.g., confirmation, invoice) for that FO will continue go through NEO CPI, even after the Shipper had migrated.
- New FOs sent from Multi-Cloud after migration will follow the Multi-Cloud path.
On day 1, the shipper sends out a Freight document, FO1, from NEO to the carrier, the carrier hasn’t responded/confirmed the FO1
On day 2, the shipper migrates to Multi-Cloud, then all new documents, like FO2 and FQ3, will be sent via Multi-Cloud
On day 3, the carrier confirms the FO1 from the carrier portal after the shipper migrates to Multi-Cloud, then the FO1 document will continue using the NEO CPI platform and routing to shipper S4 even after May 16th
On day 4, the carrier confirms FO2, then it will go through MultiCloud
- The response of FO1 is routed as follows: Carrier → (via NEO) → Network → (via NEO) → Shipper
- The response of FO2 is routed as follows: Carrier → (via NEO) → Network → (via Multi-Cloud) →Shipper
Scenario 2:
The Shipper on Multi-Cloud sends an FO to a carrier who has not been migrated yet and is still on NEO
Result:
- If the Carrier is a web carrier, the message flow is automatically handled by BN4L and works without any issues.
- If the Carrier is EDI/API integrated:
- The FO is routed as follows: Shipper → (via Multi-Cloud) → Network → (via NEO) → Carrier
- The follow-up response is routed as follows: Carrier → (via NEO) → Network → (via Multi-Cloud) →Shipper
Scenario 3:
The Shipper sends an FO from NEO, then migrates, while the carrier is already on Multi-Cloud
Result:
- Even if the carrier is already on Multi-Cloud, the carrier’s follow-up responses to that FO will continue to be routed via NEO, the integration platform was determined by the original ordering party ID when the FO was sent.
- The follow-up response is routed as follows: Carrier → (via Multi-Cloud) → Network → (via NEO) →Shipper
Scenario 4:
The shipper sends an FO from S4/HANA via NEO connection, and both the shipper and carrier migrate to Multi-Cloud later
Result:
- For the FO sent via NEO, NEO will still be used for any follow-up documents (confirmation/invoice).
- The follow-up response is routed as follows: Carrier → (via Multi-Cloud) → Network → (via NEO) →Shipper
Scenario 5:
The shipper on Multi-Cloud sends an FO to the carrier on NEO, and the carrier migrates afterward
Result:
- Multi-Could will be used for any follow-up documents
- The FO initially flows: Shipper →(via Multi-Cloud) → Network → (via NEO) → Carrier
- Follow-up response flows: Carrier → (via Multi-Cloud) → Network → (via Multi-Cloud) →Shipper
- Once the carrier migrates, new documents (including responses to new FOs) will flow entirely via Multi-Cloud.
Q: When we say “the flow triggered by NEO will come back via NEO,” which documents are included in this flow? Does it include only the FO and order confirmation, or does it also include the invoice?
Yes, the term “flow” refers to the entire lifecycle of a freight order document — not just the FO and confirmation, but also invoice documents, if they refer to that FO.
Conclusion: Any follow-up documents (e.g., confirmation, invoice) are part of the original FO flow and follow the same integration platform used when the FO was created. That’s why it’s important to keep the NEO connections and DO NOT delete it if open FO documents still exist on that platform
Q: Can shippers and carriers operate on different CPI platforms (NEO vs Multi-Cloud)?
Yes, SAP supports a hybrid scenario during the migration period. Shippers can remain on NEO while the carriers have already migrated to Multi-Cloud, or vice versa. BN4L supports the messages routes between the two CPI platforms.
Q: For the migration from NEO to Multi-Cloud, do I need to create a new web service in SOAManager to support the new CPI connection?
No, you don’t need to create a new web service.
You can continue using the existing SOAManager service in your S/4HANA system. The require action is to update the endpoint URL to the new Multi-Cloud platform HTTP endpoint.
The new endpoint should point to: https://api.logistics.eu.business-network.cloud.sap/cxf/lbn/b2b/soap/v1
(or the corresponding us.business-network.cloud.sap URL based on your region).
Follow-up: If I change the endpoint in SOAManager to the Multi-Cloud CPI URL, will this affect old documents that were originally sent via NEO?
No, it doesn’t affect them as long as you don't delete the old NEO connection in the System Connections app in BN4L.
Here’s the reason:
- Old documents (e.g., FO/FSD) created before the migration are still tied to the NEO platform connection in BN4L.
- Even after you update the endpoint in SOAManager, the BN4L system keeps using the existing NEO connection to send back follow-up responses (such as confirmation or invoice) for those old documents.
- Only new documents created after the endpoint switch will flow through Multi-Cloud end-to-end.
Q: We noticed that some message types like TransportationEventBulkNotification, TransportationOrderChargeElementRequest, and InvoiceRequest are still being processed via the NEO platform. Is this expected?
Yes, this behavior is expected and correct.
These messages are follow-up responses sent by the carriers in response to a FO originally sent by the shipper. BN4L routes follow-up responses based on the platform used to send the original FO.
For example: If a freight order was originally sent from your backend via the NEO platform, All related follow-up messages (like confirmations, events, charges, and even invoices that reference that FO) will also be sent via NEO, regardless of whether you’ve migrated to Multi-Cloud.
Important:
This is why it's critical not to delete or deactivate the old NEO connection in the Shipper System Connections app. BN4L uses that connection (Outbound) for all documents originally processed via NEO.
Q: My existing NEO connection certificates are expiring, and I want to update them to ensure business continuity. What should I do?
Ensuring connectivity should be the highest priority. It’s possible to add new certificates to your existing NEO connections. You can do the same, ensuring business continuity, and then plan your migration to the new Multi-Cloud platform accordingly.
Q: I have completed the migration and see that the new integration logs in the Manage Integration Logs app point to the Multi-Cloud platform. However, B2B messages to my carrier (with flow direction ‘Network to External System’ and ‘External System to Network’) are executed via the deprecated ‘NEO’ integration platform. Is there anything pending from my side?
There are some configuration changes that freemium customers, such as carriers, must do on their end to migrate from NEO to the Multi-Cloud platform. This is an independent activity that each customer in the network must do. Until all your related carriers have done the same, you’ll find some B2B integration logs that are executed via the old integration platform. No technical actions are pending from your side in this case. If you are in contact with your partners/carriers, you can inform them about this pending action on their end. Please find a migration guide targeted for our freemium customers here.
Final tips
- For Shippers, DO NOT delete the active existing NEO connections
- Perform full regression testing after the migration
- Keep monitoring integration logs for flow paths and failures
