How companies trade using EDI?
EDI has been around for years and most companies do EDI with Trading Partners by using either their own EDI Infrastructure or through managed EDI service providers like True Commerce, SPS Commerce, Boomi etc. The growth of managed EDI service providers offering cloud-based EDI products has been due to rapid digitalization. Companies find the need to move to the cloud or cloud-based products to be competitive, remotely access the software from anywhere, fast operation with quick updates and advanced analytics ad reporting features.
What is the problem with legacy EDI products?
Legacy EDI products are not cloud-native and lack the ability to quickly scale in this digital-era of cloud computing, mobile devices, and artificial intelligence. These products are slow and put a risk of end-of-product support and security vulnerabilities.
Plus, you need support that are still skilled in the legacy software to help troubleshoot and fix issues if they arise which are hard to find anymore.
How does Boomi iPaaS stand against legacy EDI products?
A cloud native EDI platform like Boomi can be a boon to the organization in the cloud-era. The platform:
- can effortlessly integrate with SaaS applications (SAP, Oracle EBS, NetSuite, Sage Intacct), Ecommerce Storefront Integrations (Magento, SF Commerce Cloud), Consumer360 Integrations (SalesForce Sales Cloud, Service Cloud, Marketing Cloud), HCM Integrations (SuccessFactors, SmartRecruiters), Automation with ITSM Tools (ServiceNow).
- Provides monthly updates to the platform with latest features.
- Subscription based pricing based on features and number of connectors.
Steps to follow to migrate from your legacy software to Boomi
- Assessing the current EDI environment
- Detail the migration approach
- Build Boomi integrations to match existing flows
- Testing with production samples to match existing data.
- Coordinate with trading partners to switch from legacy to Boomi EDI platform.
- Post go-live monitoring and support
Assessing the current EDI environment
As a first step, it is important to understand the current EDI environment, resources and infrastructure of your company along with the trading partners who are asking you to be EDI compliant, their communication method, and the EDI documents they would like to exchange.
In addition to that, we usually evaluate back-end your applications that you want to integrate EDI with. The backend applications can include an accounting software or an ERP, a warehouse management or a transport management software. During evaluation, we need to consider the data formats they require like JSON or XML and the connection method like an API call or an intermediate queue or a file share path.
We also like to understand the trading partner EDI communication method either through an FTP or through a VAN. Most trading partners use either AS2 or SFTP as their communication method.
Once we know your trading partners and connection method, we layout a project plan that explains the end-to-end EDI document flow from your backend system to Boomi and then to your trading partners and back from your trading partners to Boomi and then to your back-end system. The project plan also includes the migration approach which we will discuss as we go further.
After understanding the current EDI environment and laying out a project plan, we help you in installing and configuring the Boomi server, set up test/production environments and AS2 endpoints.
Boomi provides two options for runtime.
- Atom clouds – When all integration endpoints are cloud
- On-premise – When company’s resources are behind the corporate firewall
Detail the migration approach
As a best practice, we advise on migrating one partner at a time from the current EDI environment (your legacy EDI software) to Boomi unless we have strong reasons to perform big bang approach. This is called a phased approach.
We sort the trading partners based on volume of transactions and start migrating from lesser to larger volumes. This ensures that we start small, stabilize the process, and then pivot to large partners. This also ensures we take sufficient time to monitor the live partner and sort any issues if we come across any in the initial phase of migration.
If there are more trading partners that are doing EDI via VAN, we prefer to create an another mailbox with a new EDI ID and migrate one partner at a time. There have been cases where we migrated all partners from a VAN to new Boomi endpoint and it all depends on specific use cases.
Build integrations in Boomi to match existing data
Building integration process flows involves receiving/sending the EDI data to-and-fro between trading partners and ERP/TMS/WMS. This involves various processing steps such splitting, batching, translating, enriching the data so that is ready for consumption.
To understand the process flows and maps better and eventually build an exact replica in Boomi, we request access to existing EDI tools such as their process flow designers and map designers and will study the process/map code. We will also request for map specification, EDI specifications, Operations handbook, SOP documents to get a complete understanding of the existing EDI environment. Having access all the above resources helps build Boomi processes and maps and ensure that we don’t deviate from an already running implementation.
Testing with production samples
This is the penultimate step before migrating the partner to Boomi. We collect existing production samples for every document type both source and target formats and run them through the Boomi environment, and ensure the Boomi results match the existing production samples. End-to-end testing all the way from your backend system (if any) to the Boomi software and to trading partners and back is a very important part of the EDI implementation process.
- Coordinate with trading partners to switch from legacy to Boomi EDI platform
Once the process flows and maps are tested and found to match existing data, we would coordinate with the trading partner for doing a connection test with the new Boomi endpoint. Setting up Boomi AS2 requires generating private key/public certificate and specifying the right encryption/signing parameters for the AS2 protocol to work without issues. After the connection test is successful, we would agree on a date and time to switch the connection from legacy to Boomi endpoint.
- Post go-live monitoring and support
Once the integrations are up and running in Boomi, we carefully monitor the executions. We turn on Boomi platform email alerts and attend to it immediately when we spot errors. This step is so crucial after you go-live with Boomi in order to make sure there are no document failures or errors. Most companies don’t understand the importance of continuous monitoring after going-live and they end up getting charged with fines or chargebacks from their trading partners for not being proactive.