This blog is the third blog in our ‘migration to Sage X3’ series. Previous topics included the compelling business reasons along with best practices to prepare for a migration. In this blog, we’ll specifically address preparing your data for migration to Sage X3.
First, it’s important to reiterate that Sage X3 is not an upgrade from your current system. Sage X3 has a different architecture, different file structure, different individual field lengths and, depending which Sage product you might be migrating from, perhaps a different underlying database management system. Read our Migration FAQ to learn what others are asking about.
Second, there is no magical tool to convert your data from one ERP system to another. Yes, there is a migration toolkit for Sage X3 but it establishes only a starting point in the process. There are no shortcuts in exporting data from your current system, mapping the data to Sage X3 data fields, cleansing the data for validation, and then importing the data into Sage X3.
Below are some best practices that we’ve identified through Sage X3 projects and experiences.
- Clearly define your Chart of Accounts (COA), natural accounts, and segment requirements for transactional support and financial reporting. Because Sage X3 uses a concept known as dimensional account structures, the concept of pre-define account masks is obsolete. It’s important to prepare your data and setup Sage X3 correctly to optimize the dimensional properties to drive transactional ledger postings.
- Sage X3 combines traditionally separate Customer and Supplier tables into a single, Business Partner table. There are many benefits to this structure especially in multi-company environments and/or organizations that may need to net Receivables and Payables in certain instances. The point is, pay careful attention to key IDs and field length sizes which may be shorter than your current system supports.
In particular, Business Partner Address Codes can be tricky. If there is a 1 to many relationship between a business partner and various addresses we recommend:
- Using a ‘CORP’ address code for the primary address and in all other applications where it applies
- Only use alternate address codes if the following types of addresses are different than CORP
- Customer: BILL TO, PAY BY, SHIP TO
- Supplier: PUR FROM, REMIT TO
* Pay special attention to ensure that address data lookups are in synch for fields like Countries, States and Provinces.
- Sage X3 Product ID lengths are limited to 20 characters and only the following special characters are permitted: hyphen (-), underscore (_), and forward slash (/). Sage X3 Product IDs are a ‘key’ field for linking to other Sage X3 tables (product-sites, costs, prices, BOMs, etc.) so it’s imperative to establish a clean product import file early in project.
- As with Sage X3 Product IDs, the Supplier Product ID is limited to 20 characters but does allow for special characters.
Editor’s Note: Sage X3 does deliver a utility to increase field length in the database. If this is a requirement, it’s advised that this process is identified and executed in the early stages of the implementation and that all inquiry screens and required reports are documented to accommodate the enhanced field lengths.
- Sage X3 Product Description Fields are 3 separate description fields that each allow 30 characters. There is no concept for ‘Short’ description, ‘Long’ description, or ‘free form’ descriptive fields without customization.
- Sage Enterprise Intelligence connects to external databases. This is noteworthy because it can provide connectivity from your legacy system to Sage X3, thereby reducing the need to migrate historical data and transactions for reporting purposes only.
As you plan for your migration to Sage X3, we hope the above best practices will help you prepare your data to streamline a successful transition. Contact RKL eSolutions or visit our X3 migration center for more tips, tricks, and advice with your Sage X3 migration project.