Whether implementing a new system or just an additional module, your NetSuite data migration will be a critical phase. Data migration is the process of moving data from one system to another – a process that necessitates meticulous planning and execution.
In general, the data migration step of any project is the step companies are least worried about and consequently the one they trip up on the vast majority of the time!
This is one of the biggest risks for your project timeline.
The NetSuite data migration process requires strong engagement and careful attention from multiple key individuals in the business. Data needs to be, not only accurate, but cleansed, useful and formatted to NetSuite requirements.
It is critical, for all involved to allocate sufficient time and attention to the process as early on as possible.
In this article I will explain all aspects of the data migration process for both full NetSuite implementations and smaller projects. I will shine some light on common mistakes and highlight the areas that need extra care and attention to ensure success.
What is Data Migration?
When it comes to NetSuite data migration is the process of transferring data from your legacy system to your new NetSuite environment.
This may be a manual process of exporting, manipulating and then importing. Or it may be more automated, via scripts or even a middleware.
Data is, of course, a very broad term. The information being migrated can be broken down in to two clearly defined categories.
- Static Data
- Transactional Data
Static Data Migration
Static Data is technically data that doesn’t change after it is recorded. Most data can be changed though so you might prefer the alternative term Master Data.
More appropriately, it can be defined as relating to people, places and things. Although your NetSuite static data is more broad than that, it certainly gives you a starting point –
- People – Customers
- Places – Locations
- Things – Items
You’ve also got such data groups as vendors, departments, chart of accounts and so on.
Static data, although as we have established it can change, does not move quite as fast as transactional data. This means it can be prepared and provided earlier in a project than financial balances.
A typical NetSuite financials implementation will request the following static data from the customer as early as possible.
|We can’t proceed with anything else without knowing the full list of subsidiaries to be setup. Most companies have a simple enough structure that this can just be entered manually in to a template.
|Chart of Accounts
|After the subsidiaries this is the most important piece of data for any implementation. An implementation is a great opportunity to cleanse and rationalize a chart of accounts so this should be encouraged.
|Classifications (Department, Class, Location)
|Other systems may use different labels for these classifications but most businesses will be using some sort of segmentation for their financial data. Additional segments can be set up using the Custom Segments feature.
|Businesses may decide to take a position on which customers to migrate over. All historical data or only customers that have transacted in the last year, for example.
|You may take the same approach here as explained above. Don’t waste time migrating vendor data that is no longer relevant.
|This may be straight forward if all customers and vendors use the same payment terms. If it is more detailed than you might need to investigate how this data can be extracted from the current system.
|Consider whether this will be for HR purposes or if only NetSuite users need an Employee record.
|Preparing items for import can be hugely time consuming. Thought needs to be put in to which item type to use and, as with all these data points, the list will likely need to be cleansed before migrating.
|This may be a new concept to customers coming from another system but they will likely have used something similar. For many implementations, new expense categories are formulated rather than current ones migrated.
Transactional Data Migration
Transactional data is what will make up the values on the trial balance. There are two typical approaches to the transactional data migration.
Trial Balance and Open Transactions
- Trial Balance values at go live imported via journal.
- Open Sales Transactions imported.
- Open Purchase Transactions imported.
- A full transactional history to populate the trial balance through actual source transactions.
Many businesses will expect to have a full transactional history. However, once the project begins and the burden of this task makes itself clear, 99% of businesses will settle with the first option.
On the rare occasion that I have done a full transactional history import it is normally for businesses that have been operating less than a year or so.
Using reversing journals at month end, trial balance values can be loaded for every month going back a couple of years if necessary. This is normally sufficient to facilitate historical reporting.
Open transactions include –
- Sales Invoices that have not been paid.
- Vendor Bills that have not been paid.
- Optionally, Purchase Orders that have not been exhausted.
- Optionally, Sales Orders that have not been fulfilled.
There are some additional transactions that a business might want to consider. If you are an end user, be aware that your consultant might expect you and your accounting team to be thinking of this yourselves –
- Amortization schedules.
- Recurring journals.
- Revenue recognition schedules.
- Depreciation of fixed assets.
The Data Migration Process in a NetSuite Implementation
NetSuite data migration involves a structured process, carefully executed to ensure a smooth transition. Showing due care and attention will minimize the risk of lost or damaged data.
Here’s a high-level overview of the steps typically involved:
Assessment, Planning and Preparation
It’s almost never too early to start discussing data when working on an implementation. As early as possible, the NetSuite data migration process should be discussed.
The end users should be assessing their current data. They need to investigate how to extract it from their legacy system. They should be asking questions about the format, whether it needs cleansing, whose responsibility each dataset is etc.
The consultant running the project should be introducing the data migration timeline. All key project team members need to understand what data is required when and in which format.
Data needs to be extracted from the legacy system. If the correct planning and preparation has been carried out, this should be a simple task.
Normally this is something the end user can carry out themselves. There are some systems, however, that require specialist knowledge to extract the data. Don’t wait until the data needs to be extracted to find this out.
Data Cleansing and Transformation
I have mentioned data cleansing a few times already but what does this mean?
Data cleansing is the task of ensuring the data to be imported is correct and current. If you are preparing customer data, for example, take this opportunity to ensure the the addresses and contact details are correct.
A wise man once said Put rubbish in and you’ll get rubbish out!
As well as making sure the data is correct, you might want to slim it down to ensure it is current. Do you need to import customers you haven’t dealt with for 10 years? Do you care about vendors you purchased one widget from and it didn’t work? Ask these questions and act on the answers.
Once the data is cleansed it will need to be transformed in to the correct format. NetSuite provide a number of standard import templates with instructions for each column. The consultant in charge of the project may also have their own templates they can provide.
Pay special attention to list fields in NetSuite. For example, a country field in NetSuite may have the value United Kingdom and not England or Great Britain.
The data will then need to be loaded. This will happen at a number of different points in the project.
When carrying out an entire NetSuite implementation there may be data loads at the following points –
- Sample static data prior to walking through the system.
- Sample transactional data prior to walking through the system.
- Complete static data prior to system testing.
- Complete transactional data prior to go live.
- Delta static and transactional data after go live.
As previously mentioned, the entire NetSuite data migration process should be discussed as early as possible so none of the above is a surprise.
Validation and Testing
After each tranche of data is loaded, it should be validated by a member of the relevant team.
This is not an important step for sample data being used during training and walkthroughs. All data being loaded to the production environment, however, should be signed off by a suitable person.
Import Templates for NetSuite Data Migration
Data import templates are essential tools to facilitate the loading of data into the NetSuite platform. This can be anything from your Classifications and Chart of Accounts to transactions such as Invoices and Sales Orders.
These templates provide a structured format where you can organize your data as per NetSuite’s requirements. Import templates ensure your data aligns with the specific fields and structure of NetSuite.
NetSuite offers various data import templates that can be found in their asset hub, your NetSuite file cabinet or can be provided by your project consultant. These templates typically come in an Excel format with additional information above each column to explain the required input. Once ready, the data and column headers can be copied out and saved as a CSV ready to be imported.
If you are creating your own templates remember to include all the mandatory fields of the target record as a minimum. It’s also useful to use column headers that match the field names exactly – this will aid the field mapping.
Typical Points of Failure in the NetSuite Data Migration Process
While data migration is a structured and methodical process, there are potential points of failure and risks that need to be recognized and avoided.
Here are some common causes of a failed NetSuite data migration process:
The greatest benefit of introducing the data migration very early on in the project is to stir up engagement.
The responsible parties need to take this job seriously. Without all the right data, you do not have a successful go live.
Ensure everyone understands the importance of the task and a number of hours is dedicated to each section from the very start of the project through to the end.
Data Quality and Consistency
This speaks to the importance of attention to detail and data cleansing. Trying to import incomplete, corrupt or low quality data will result in a troublesome go live.
Ensure the right people are reviewing, cleansing and correcting the data before it is ready to import.
Use some some common sense and consistency when preparing data. Remember England ≠ Great Britain ≠ United Kingdom.
Volume and Complexity of Data
Underestimating volume and complexity will present real problems for the project. An analysis of these two factors early on may also dictate the NetSuite data migration approach.
When discussing transactional data for example, do you want a full transactional history for a given period or just trial balances?
If you operate an external webstore, do you need to bring in complex product data?
Under items, do you offer individual SKUs for color and size combinations or are these covered by segments and other indicators?
Lack of Testing
Importing full datasets in to production should be done with confidence and a host of testing behind it.
Start by importing sample sets in to Sandbox whilst full datasets are still being compiled. Then import full datasets in to Sandbox and get these signed off before the production account is ever considered.
Insufficient Training and Expertise
If there are people in the business that work with large volumes of data regularly, get them involved. All too often I see people assigned tasks that they are not capable of and this results in poorly processed data or delayed timelines.
Just because Joe works in Accounts Receivable, that doesn’t mean he knows how to efficiently and methodically cleanse a spreadsheet of 10,000 customers’ data.
Mitigating these potential points of failure requires a thorough understanding of the process, comprehensive planning and rigorous testing to ensure a successful data migration into NetSuite.
Charting a Smooth Course for NetSuite Data Migration
NetSuite data migration requires careful planning, precise execution, and the right tools to navigate through the volumes of data.
Understanding what data migration entails, the process involved and the potential points of failure will allow your business or customer to undertake this stage of the project with confidence.
Use the steps outlined above to build a solid plan through the migration and stay aware of the potential risks.