Migrate from Edicom to Infor CloudSuite Corporate

Edicom trading partner profiles contain connection settings (AS2 ID, VAN address, HTTPS endpoint), supported document types (ORDERS, INVOIC, DESADV), certification status, and contact data. We export profiles as structured records and create a corresponding custom object in CloudSuite (Partner_Endpoint__c) with fields mapped to the Edicom schema. The custom object is provisioned during schema design before any data import. Partner re-activation is sequenced in waves by transaction volume, with a shadow-mode period where both platforms receive live documents before final decommissioning of the Edicom endpoint.

Edicom translation maps translate between partner EDI formats (X12, EDIFACT, VDA, ODETTE) and ERP data structures. Each map has source/destination field mappings and transformation rules. Many customers have custom-developed intermediate data tables and equivalence lists referenced in map logic but not stored as first-class Edicom objects. We discover and export all referenced tables during the mapping phase and replicate their contents as lookup tables in CloudSuite's data model. EDI standard and version per connection is captured and mapped to destination-compatible equivalents in the Infor OS configuration layer.

Edicom message flows define which EDI transaction types are active for each trading partner relationship. There is no native EDI message flow object in Infor CloudSuite multi-tenant. We design a custom configuration table (EDI_Flow_Config__c) that records the mapping between each partner_endpoint__c record, the supported document type, the direction (inbound/outbound), and the Infor ION workflow that processes it. This configuration table is the reference document for the customer's admin when re-establishing connectivity at the destination.

Edicom's long-term archive (EDICOMLta) stores transaction evidence with timestamping and digital signatures from an accredited third party. We export archive records as structured data files and import them into CloudSuite Document Management with evidentiary metadata preserved as file attributes. The embedded digital signature context is preserved as metadata but is not independently verifiable in CloudSuite; we advise customers to retain read-only Edicom archive access or re-validate signatures before treating exported files as standalone legal records. The Infor Data Lake option is recommended for organizations with multi-year retention requirements, as it handles large historical volumes without degrading CloudSuite transactional database performance.

AS2/AS4 certificates, TLS credentials, and signing keys provisioned under Edicom's account structure cannot be downloaded and uploaded elsewhere. They must be re-issued by the certificate authority or re-negotiated with trading partners. We flag every certificate-bound connection during scoping, map each to its partner_endpoint__c record, and coordinate re-issuance timelines with the cutover schedule. New certificates are provisioned through Infor ION security configuration. No certificate data migrates directly; the mapping notes document the CA, serial number, expiry date, and re-issuance contact for each partner to prevent connectivity gaps.

Edicom connects to ERP systems via middleware, intermediate data tables, or direct API/WebService calls. CloudSuite does not support direct database-level integration. We document the current Edicom-to-ERP connection architecture, then re-establish equivalent integrations using Infor ION or approved API methods. Intermediate data tables that feed ERP data into Edicom are replicated as reference tables in CloudSuite or mapped to corresponding CloudSuite master data (items, customers, vendors). Integration rebuild is not within migration scope; we deliver the integration architecture document and the customer or an Infor implementation partner rebuilds the ION connections.

Some Edicom integrations use customer-specific intermediate data tables or equivalence lists that are not documented as first-class Edicom objects. These are often maintained by a single developer and are discovered only through schema analysis. We export these tables as structured data during the mapping phase, validate their contents and update frequencies, and replicate them as CloudSuite reference data tables or custom fields on the relevant master data objects. Update-frequency documentation ensures the customer can maintain these tables post-migration.

Edicom logs capture timestamp, status, and content hash for each processed document. We export historical logs for the retention period the customer specifies and load them into CloudSuite's audit trail or Infor Data Lake for querying. Content hashes are preserved as metadata fields on the corresponding document records. Log volumes from high-volume EDI operations can be substantial; we recommend the Infor Data Lake for organizations requiring multi-year log retention to avoid degrading CloudSuite transactional performance.

Edicom's Managed Services option provides 24x7 supervision, administration, and maintenance by a dedicated technical team. Migration requires a handoff plan so that Edicom's support team stops monitoring transferred connections on a defined date. We document the current monitoring scope, alert thresholds, and escalation contacts, and deliver this as a runbook for the customer's new monitoring team (whether Infor CareFor Managed Services or internal). CloudSuite monitoring is reconfigured post-migration by the Infor team; we do not migrate alert rules directly.

Edicom supports multiple EDI standards (X12, EDIFACT, VDA, ODETTE) and version variants per trading partner. We capture the standard and version for each active connection during discovery and document the mapping to destination-compatible equivalents. Infor ION handles protocol translation; the standards metadata is recorded in the EDI_Flow_Config__c custom object so that connectivity testing at cutover validates the correct standard version is active for each partner.

Edicom handles country-specific e-invoicing formats and tax compliance rules as part of the translation layer. Infor CloudSuite includes country-specific fiscal and tax compliance capabilities through its industry-specific suites. We extract the active e-invoicing schema configurations from Edicom (XML schema references, SAF-T mappings, fiscal ID assignments per country) and document them as a compliance reference for the customer's Infor implementation team to configure in the CloudSuite tax module post-migration. This is not a direct data migration; it is a configuration handoff that prevents compliance gaps when live e-invoicing traffic resumes in CloudSuite.