Logistics and distribution
Infor SX.e and CloudSuite Distribution: keeping your sales history
By SourceX Editorial · Updated
Short answer
An Infor SX.e migration, whether to CloudSuite Distribution or another ERP, is the moment sales history is most often lost. Before cutover, export full order, quote, invoice, credit, customer, product and pricing history with the IDs that link them, plus notes and attachments, and keep a read-only archive with an old-to-new ID map.
Key takeaways
- Conversion scope and history retention are separate decisions, and a migration project is usually built around the first.
- Export detail-level order, quote, invoice and credit history, not summary reports.
- Notes, attachments and user-defined fields hold much of the context and are the easiest to leave behind.
- Confirm in your license or hosting agreement how you can reach the old environment's data before it is retired.
- Keep the old-to-new ID map with the archive so history still joins to the new system.
What sales history is at risk in an SX.e move?#
Sales history in an SX.e move is at risk wherever the conversion plan stops short of full detail. Migration projects, whether to CloudSuite Distribution or to another ERP, are usually scoped around what the new system needs to run: masters, open orders, open receivables and some summary history.
The rest can stay behind: closed order lines, quotes and lost sales, credit memos and returns, pricing and rebate history, customer and order notes, and attachments. Whether that history is converted, archived or simply left on an old server depends on the project scope, the partner and your hosting arrangement, so the question has to be asked out loud.
For a distributor, that history is the record of how customers buy: substitutions, price overrides, returns and repeat patterns. Losing it weakens forecasting and pricing analysis, and it removes options for any later use of the records, including a licensing review.
What should be exported before the upgrade or move?#
Before an SX.e upgrade or move, export every record family that carries transaction history, at detail level and with the keys that link it. The table lists what to include and which keys to keep for each family.
Closed and inactive records matter most here. A conversion that loads only active customers and products leaves behind the history of discontinued lines and lost accounts, and those records often explain why customers left or switched products.
| Record family | What to include | Keys to keep |
|---|---|---|
| Sales orders | Headers and lines, including closed, canceled and backordered lines | Order number, line number, customer, ship-to, product |
| Quotes and lost sales | Quoted lines, conversion status and lost-sale reasons | Quote number, customer, product, salesperson |
| Invoices and credits | Invoice lines, credit memos, return reasons and RMAs | Invoice number, original order, credit reference |
| Customers and ship-tos | Active and inactive accounts, terms and hierarchies | Customer number, ship-to code, parent account |
| Products and warehouses | Product master, units, supersessions and warehouse records | Product code, warehouse, vendor product number |
| Pricing and rebates | Price sheets, contract pricing and rebate records | Price record, customer, product, effective dates |
| Purchasing | Purchase orders, receipts and vendor returns | PO number, vendor, product |
| Notes and attachments | Order, customer and product notes and linked files | Parent record type and ID |
How can the data be extracted?#
SX.e data can usually be extracted through the application's own reports and export tools, through direct database access where your deployment allows it, or through tools supplied by Infor or an implementation partner. Which route is open depends on whether SX.e runs on your own servers or in a hosted arrangement, and on your license and hosting terms.
Reports are convenient but often summarize or truncate. Database-level extracts keep detail and keys but need someone who understands the data model, including user-defined fields and custom tables added over the years; partner tools can be fastest when a partner already maps the data, but confirm they export history and not just conversion files.
Ask the access question early. Before signing a CloudSuite or new-ERP contract, confirm in writing how you will reach the old environment's data, for how long and in what format, and put the answer in the project plan.
A history-keep checklist for SX.e#
A history-keep checklist turns a vague intention into a sign-off item that blocks shutdown of the old environment. Use it alongside the migration partner's conversion checklist, not instead of it.
Give each line an owner and a target date, and keep the old environment running until every line is signed off. The checklist is short on purpose, so it can sit on the cutover plan where the project manager sees it.
- Agree in writing which history is converted, which is archived and which is discarded.
- Export detail tables for orders, quotes, invoices, credits, pricing and purchasing, including closed and inactive records.
- Export notes, attachments, user-defined fields and custom tables with their parent IDs.
- Export EDI history and any document imaging linked to orders and invoices.
- Build and keep the old-to-new mapping for customers, ship-tos, products and warehouses.
- Write a short data dictionary for key fields and code values such as reason codes and order types.
- Validate the archive by tracing sample orders from quote to payment before the old system is shut off.
- Store the archive in an open format with named owners and access controls.
Mistakes that lose SX.e history#
The mistakes that lose SX.e history are mostly timing and scope mistakes rather than technical ones. Each is cheap to prevent before cutover and expensive, or impossible, to fix afterward.
| Mistake | Consequence | Prevention |
|---|---|---|
| Retiring the old environment before validating the archive | Gaps surface when nobody can fix them | Make archive validation a shutdown gate |
| Exporting summary reports instead of detail | Line-level history and keys are lost | Extract detail tables with their IDs |
| Dropping notes and attachments | Context for credits, overrides and returns disappears | Export notes with parent record IDs |
| Ignoring user-defined fields and custom tables | Company-specific data vanishes | Inventory customizations before extraction |
| Leaving reason codes undocumented | Codes become unreadable later | Write a data dictionary |
| Forgetting EDI and imaging systems | Breaks in the order-to-cash chain | List every system connected to SX.e |
Illustrative: an HVAC and plumbing supply distributor leaves SX.e#
Illustrative: a fictional HVAC and plumbing supply distributor has run SX.e on its own servers for many years and is moving to CloudSuite Distribution. The partner's plan converts masters, open orders, open receivables and summary sales history.
The IT director adds a history-keep workstream. A database administrator extracts detail tables for orders, quotes, lost sales, invoices, credits and pricing, along with order notes and user-defined fields, and the controller documents credit and lost-sale reason codes in a data dictionary.
Before the old servers are retired, the team traces sample orders from quote to payment in the archive and repairs the missing joins it finds. The archive and ID map are stored with named owners, and the history later supports pricing analysis and a metadata-only licensing fit check.
Why kept history matters beyond reporting#
Kept SX.e history matters beyond reporting because years of linked distributor transactions are the kind of operational records AI developers license, and they cannot be recreated once the old environment is gone. A clean, documented archive is also easier to use for your own analytics and internal AI tools.
SourceX assesses archives like this through the SourceX five-step transaction, starting in Supply with metadata only: system, years, record families and whether keys still link. The SourceX Evidence Packet documents where the archive came from, how it was exported and which ID map joins it to current records, so anyone relying on it later can trace its history.
Frequently asked questions
Does a move to CloudSuite Distribution bring all SX.e history across?
Not automatically. What moves depends on the conversion scope agreed with Infor or your implementation partner, and many projects convert masters, open transactions and limited history. Ask for the scope in writing, and plan a separate archive for everything the conversion leaves out.
What format should the archive use?
Open formats that do not depend on the old application, such as CSV extracts or a database backup your team can restore and query, plus a data dictionary and the ID map. Test that someone outside the original project can answer a real business question from the archive.
How long should the old SX.e environment stay available?
Long enough to validate the archive against real questions from sales, finance and operations, and to cover any audit, tax or dispute needs counsel identifies. Check license and hosting terms for access after cutover, because the end date may be set by contract rather than by you.
Should we keep user-defined fields and custom tables?
Yes, at least in the archive. Distributors often store important company-specific details there, such as job names, contractor programs or special handling flags. Inventory the customizations before extraction so none are missed, and document what each field meant.
Who owns the data in a hosted SX.e environment?
Your agreement with Infor or the hosting provider governs ownership, access and return of data. Customers usually expect to own their business records, but the practical questions are how, when and in what format you can extract them, so read those clauses before a renewal or migration decision.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.