X12’s Fall 2020 Standing Meeting Will Be Virtual

The X12 Board and staff appreciate every X12 member representative and want to thank you for your contributions as a collaborator, implementer, and advocate of the consensus-based, interoperable, syntax neutral data exchange standards powering global business to business exchange today and into the future.

The coronavirus continues to upend lives and activities around the globe. Business interruption, travel restrictions, and social distancing remain the norm. Considering the current COVID-19 situation and X12 leadership’s focus on the health and safety of our member representatives, the X12 Board of Directors has voted to conduct the X12 Fall Standing Meeting as a virtual Standing Meeting.

The standing meeting, originally scheduled to be held in Cincinnati, Ohio, will be conducted via webinar. The meeting will be held over the scheduled dates, convening on October 4, 2020 and ending on October 14, 2020. Registration opens in the next few weeks and all participants will need to register to attend.

X12 staff is currently working with the chairs and co-chairs of X12 groups to confirm or revise the standing meeting sessions their groups will conduct. Information about registering for the Fall 2020 Standing Meeting and other logistics will be sent to you via email once the session schedule is finalized.

If you have a hotel reservation booked under the X12 room block at the Hilton Cincinnati Netherland Plaza, the hotel will cancel your reservation automatically and send you a cancellation confirmation soon. If you booked outside the room block, you need to cancel your reservation yourself. Questions about hotel reservations should be directed to This email address is being protected from spambots. You need JavaScript enabled to view it..

We will miss seeing you in person this fall and look forward to collaborating with you in person again as soon as possible. Thank you for your continued participation and support as we all navigate these turbulent times.

Cathy Sheppard
X12 Executive Director


The form was submitted

X12 Logo

Best Practices Migration White Paper

Executive Summary

This document, which has been approved by the X12 Standards committee, outlines the best practices for migrating to and from a new EDI Service Provider.

This document is not intended as a defacto or Standard Operating Procedures document, but as best practices guidelines to assist companies of all sizes in all industries in the process of migrating to a new service provider.


Migrating your Electronic data from your current EDI Service Provider to another provider can be a daunting task for your ED organization to complete. The key challenge lies in keeping not only IT, but all project stakeholders across the enterprise, informed and working together smoothly toward the same goal-despite their disparate roles and project responsibilities.

To ensure a successful EDI Service provider migration, you need a solid approach / methodology that covers discovery, analysis, planning, and execution. But this alone is not enough to ensure success. If you are moving just a few EDI IDs or transactions, it's no big deal. However, when moving hundreds or even thousands of trading partner EDI IDs, dozens of EDI transaction sets, the associated special handling rules while minimizing the business impact, becomes a most formidable endeavor.

Approach and methodology

At a high level, most EDI Service Provider migration methodologies appear to be similar. The core phases of initiation, discovery, analysis, planning, execution, and maintenance are pretty standard. The challenge is in how the details are managed and orchestrated.

Ensuring Success

Before starting a migration project, you need to have a complete and comprehensive view of the project, all the while anticipating each step along the way and how it will impact the whole migration project. At the start of the migration, stakeholders must agree on the assumptions related to resources, capacity, bandwidth and timelines. Any unrealistic expectations on the size and scope of the project must be clarified with the business else you risk undesired results such as delays or unhappy trading partners.

Migration phases

  1. Discovery
    Take an inventory of all your EDI trading partners to include the following:
    1. List of all EDI transactions traded
    2. All EDI IDs used
    3. Contact information for every trading partner
    4. Any special handling processes, such as carbon copying, delimiter conversions, remapping, etc.
    5. Identify and understand all interdependencies across all applications and infrastructure processes.
    6. Understand how the business will be impacted as processes are migrated to the new Service Provider
    7. Determine if any of the customers trading partners will require testing or recertification due to the migration to a new EDI VAN provider.
  2. When the project discovery process is not pursued with the end goals in mind, the phase could expand unnecessarily and delay the start of the migration.

  3. Planning and Analysis

    Upon completing the discovery phase, ensure all findings are documented and validated. During the analysis and planning phase you will be performing strategic decision-making to minimize any migration risks and understand what activities will impact your organization throughout the project.

    You'll need to decide if the migration is going to be a "hot migration" where you move everything all at once on a designated day. Or, will there be multiple smaller migrations (slow migration) where EDI processes are divided by trading partner group, transaction set or business sector.

    • Hot migration - Usually done when all trading partners must be migrated to new VAN at same time
      • If Hot migration, then:
        • Complete list of all trading partners and IDs and planned date for migration
    • Phased migration - Usually done when there are logical groupings to the trading partners or when a business need requires the migration be done via a phased approach. There are also some EDI VANs who enforce a limit as to how many trading partner EDI IDs they will migrate in a day, thus necessitating a phased approached to the migration.
      • If a Phased migration, then:
        • Completed list of phased partners/transactions for each phase and when phase will occur

    Regardless of whether you decide to perform a hot migration or slow migration, understanding all the interdependencies of your EDI system is critical. Typically, various groups in an organization will have different outage tolerances and the plan must take these variances into account. For example, there is less tolerance with outages affecting end customer satisfaction as compared to various internal-use applications that are not as mission critical.

  4. Execution

    Timely communication, concise objectives and instructions, clear task ownership and full visibility throughout the process will significantly improve your chances of success. But how do you achieve this? What's the magical elixir to ensure the migration goes as planned without unexpected issues? Rest assured there will be issues but how you mitigate them will make all the difference. To help you lessen the risks and increase your odds of a successful migration, we have provided a Migration Checklist which when followed will mitigate unexpected issues and help the whole process flow more smoothly.

  5. Maintenance

    An EDI Service Provider migration is much like moving into a new home. Everything is clean, organized, and landscaped just the way you want it on day one. However, it can quickly fall into disarray if you fail to do regular maintenance such as cleaning up unused EDI IDs, outdated contact lists and lack of good record keeping. In preparing to move to your new EDI provider you cleaned and validated the data, and have it well mapped out and documented. To keep everything running smoothly, consider implementing on-going EDI ID cleanup to remove old unused EDI IDs or connections and send out annual EDI surveys to your EDI trading partners to ensure you have the correct contact info for their EDI team.

Note, all migrations will have some uniqueness to them, thus the checklist below should be used as a guideline and not a defacto list of all items needed to ensure a successful migration.

EDI Migrations Best Practices Check list

Hot Migrations

Working under the 'hot migration' (all at once, existing ID's) model, with standard format pass-thru, it is best to have the migration team ensure the following:

Responsibilities of the customer who is migrating

  • Review any contractual agreements with the current provider. Items of interest include dates (evergreen rollover, current term expiration, notification to cancel, etc.) and cancellation policies (method of notification, possible charges).
  • List of company and partner ID's and content formats (X12, EDIFACT, VDA, etc.), this includes non-mapping based (default) delimiters and formatting (streamed, wrapped, blocked)
  • Credentials for any direct-connects (Amazon, Wal-Mart, etc.)
  • Any current custom VAN content manipulation (mapping, defined delimiters, CRLF/blocked/streaming)
  • Any current VAN direct/hosted connections (Amazon, Wal-Mart, other)
  • Determine transaction types traded (X12 or others such as EDIFACT, XML, etc)
  • File naming conventions/rules
  • Establish the migration deadline (1month (min 2 weeks) before the end of the existing VAN contract)
  • Migration authorization letter: Logo/Letterhead, migration date/time/time zone, authorizing agent hand written or certified digital signature with full contact information (optional technical contact, if separate)
  • Post-migration legacy VAN polling and tracker review to ensure processing of in-transit data
  • Client should monitor their traffic to verify that they received at least one transaction per TP and that all
  • outbound documents have been acknowledged
  • Termination of prior VAN agreement
    • Confirm they are current with last invoice
      • It is recommended the service provider release EDI IDs even if there is still remaining contract balance and collection of any remaining balances be handled separately.

Responsibilities of the new EDI Service Provider

  • ID validation - Includes identification of current/future interconnects (VAN, hosted, etc.), testing requirements
  • Confirm what network the trading partners are on
  • Scheduling: M-Th, 11:30AM-4:30PM Eastern, no off-hours, weekends, days immediately preceding holidays.
  • Authorization Request:
    • Logo/Letterhead (top of form)
    • ID's
    • Date, time, time zone
    • Hand written or certified digital signature
    • Authorizer's contact credentials (title, phone, e-mail)
    • Inter-VAN distribution to take place, at least, 5 business days prior to scheduling
  • Direct Connection and multi-VAN shared ID partner scheduling notification
  • Post-migration VAN and Direct Connection compliance confirmation
  • VAN and Direct Connection activity validation & ACK review
  • User Interface (Document Tracker) support training
  • VAN/Service provider to monitor traffic for up to two weeks (Hypercare)

Mapping (if needed)

  • Gather specifications (EDI Guidelines, Flat file layouts)
  • Gather samples of current data exchanged
  • Complete GAP analysis (if required)
  • Complete mapping and confirm it meets clients and trading partners needs. This step must be done prior to the actual migration.

Responsibilities of third-party VAN involved in the migration (trading partners VAN's)

  • Pre-migration: Confirmation of receipt and scheduling of migration request
  • At-migration: Effects routing table updates as requested
  • At-migration: Confirmation of request fulfillment
  • Post-migration: VAN and DC compliance confirmation

Ease of doing business

You should ask your current provider for the following to ensure a smooth migration and not create any un-necessary hardships to companies in the process of migrating.

  • File with every name, qualifier and network they are connected to
  • Spell out Direct Connects - AS2 - carbon copies and delimiters -

Slow or custom migrations

There are variations to the Standard or full migration, and they are often referred to as a Slow Migrations or custom migrations.

Slow Migrations or custom migrations are often done with the migration process being executed in logical groups by EDI ID, trading partner grouping or even by document type. Slow migrations can also involve migrations where several different VANs are involved with each one having responsibility for different trading partners or custom configurations.

Given the various deviations that can occur from the above, i.e. slow migrations to new ID's, multi-VAN ID sharing, multi-date migrations (DC's vs. VAN), etc., it is not recommended to use a 'standard' checklist to enact a migration, however, a more custom checklist using aspects of the Hot migration checklist can be used to ensure all items are taking into account.

Due to the uniqueness of Slow migrations, the new VAN provider should be consulted in creation of the migration model ensuring a smooth stress-free migration.

Migration Day

Performing the actual migration of EDI IDs to the new VAN will need to be coordinated to ensure all IDs get migrated on an agreed upon schedule.

All Service providers will have a limit to how many EDI IDs can be migrated per day. The reason for the imposed limit is it takes time to make the actual changes in the routing configuration, thus bandwidth constraints need to be considered.

Most VANs and service providers should be able to migrate a low count of EDI IDs, however if you have many EDI IDs in need of migration, it is best to coordinate ahead of time with the TP's VANs to ensure they will be able to handle all your IDs on the requested date/time.


Virtual Session Request Form

This form is filled in by an X12 group's leadership. Hover over a label for help. All fields are required, enter NA if not applicable for your group.

Group ID
Chat Master
Session Logistics
Session Type
X12 Logo

EDI Testing and Certification Best Practices

Executive Summary

This document, which has been approved by the X12 Standards committee, outlines the Supply Chain Industry best practices for EDI testing and certification.

This document is not intended as a standards document, but as best practices guidelines to assist trading partners of all sizes in all industries in the testing and certification of their EDI initiatives.

Implementation Guides


Implementation Guides are EDI specifications (which are usually a subset of the entire specification of a specific version) that provide trading partners with detailed element and segment by segment requirements for doing electronic business in an agreed upon format.

The accuracy of these guides is important to both the creator and the implementer. By having valid and accurate guides, the interpretation is easily understood, and the testing cycle is greatly reduced.

X12 also publishes implementation guides, known as Type 3 Technical Reports (TR3). In a TR3 each segment and element are assigned as either Required or Situational. When the assignment is Situational, there is a Situational Rule that indicates the circumstances when the segment or element is required.


  • Association-based implementation guides have their own interpretation
    • GS1, encompassing UCS, VICS, WINS and others
    • Tradacoms
    • Others
  • Company-based implementation guides have their own interpretation, sometimes based on association guides, but not always
    • Walmart
    • Nordstrom
    • Penney's
    • Levis
    • Others
  • Guidelines that are not created with commercial tools, and are in spreadsheet or Word format
  • Guidelines that don't properly implement the X12 Standards, for example, not adhering to X12's data types, and minimum & maximum lengths
  • Guidelines that contain content and rules outside of the X12 Standards

Best Practices

  • Implementation Guides should be created as a TR3, and if not, using commercial EDI specification builder software such as:
    • EDIFECS Spec Builder
    • TIBCO Foresight EDISIM
    • Others
  • Transaction structure of the guide:
    • Guides should contain the high level Header, Detail and Summary information for the full transaction. This information should contain all required segments, the looping structure and the usage requirement for each segment.
    • Implementation guides should only contain segments and elements that are required to be used per the X12 standard as well as the creator's individual requirements.
    • Additional segments that are not used should not be included in the guide.


The following partial sample of a transaction structure is from a TR3

  • Segment Detail section of the guide:
    • Guides should contain detailed information for every element used within a segment.
    • For a TR3, elements are specified as required or situational
    • For other implementation guides elements should be clearly defined as mandatory, conditional or optional in relation to the X12 standards, as well as with the guide creator's specific requirements
    • All code list elements should be explicitly defined, as well as any specific data size limitations that may not be the same as defined by the X12 standard. For example, if a PO number for your company can only be 8 characters long.
    • Ideally, a sample of the segment as you expect to see it should be included.

The following sample of segment detail is from a retailer implementation guide, detailing only what elements are required in the mapping.


Test Data


  • Partners are not using real test data.
  • All segments and elements fields in guide are not in test
  • All possible scenarios are not tested
    • Bulk
    • Cross Dock
    • Drop Ship
    • Others
  • Testing needs to be tested both against the standards, as well as the implementation Guides
  • Partners are transmitting test transactions with the ISA015 Production "P" indicator and not the test "T" indicator.

Best Practices

  • Test Files
    • When submitting test data to your trading partners, only real test data should be used.
      • Item numbers, UPC numbers, vendor numbers, ship-to locations, others
    • By using real data, it allows the trading partner to process the transactions through their systems naturally and without manually editing files. EDI is meant to be tested machine to machine, not text editor to machine. Realistic data allows tests to be representative of a live transaction lifecycle.
    • Test files should include all segments and elements marked as required in the implementation guide. To produce accurate mapping and data in, data out scenarios, the data must be available for the test. Sending incomplete documents does not accurately confirm the mapping and processing is complete on both sides.
  • Multiple Scenarios
    • If there are multiple scenarios spelled out in your implementation guide, then all scenarios must be tested. For example, if you specify differences in the EDI format for Bulk Orders, Distribution orders (Cross Dock, SDQ) and drop ship orders, you must test all three scenarios. Every scenario must be tested and approved to complete an all-inclusive certification. By omitting scenarios during the testing phase, there is great risk of faulty transactions when in a live environment that can disrupt business for both parties.
  • Standards Validations
    • Test files should not only be validated against the implementation guide, but also against the EDI standard. Segments out of place, invalid qualifiers, missing mandatory elements, others, should not be allowed.