Data migration is one of the key activities you will undertake as part of a NetSuite implementation. Getting it right will help with help your finance team hit the ground running post NetSuite go-live. Optimal data quality will reduce your team’s time to process tasks meaning your finance function will see the new system benefits earlier.

Most organisations will admit that there are gaps in their historic data. In busy organisations, data completeness is usually overlooked to just meet requirements. Moving to NetSuite will likely mean you can automate more processes, quite often though this automation will require good standard underlying data.

Assuming your organisation falls into the above category getting optimal data into NetSuite will come with costs. High-quality data will likely require project resources and will likely delay go-live meaning decisions must be made. Here are 5 tips that will provide a framework for assessing these trade-offs and making these decisions:

 

1. Identify the data you would like to migrate

The first step is to identify the data that you want to migrate across all NetSuite modules. An implementation partner will help with this and can tell you what data is required e.g. supplier objects, customer objects, opening balances etc.

It will get a little bit trickier when you get into the specific data fields within the above for example do you want to load customer phone numbers and addresses? Do you want to load supplier bank details? You may not have answers to these questions straight away but it is useful to begin to find out the implications of these to future NetSuite processes

The big question we always ask clients is if they would like to migrate transactional-level data as this can add a lot of time and cost onto the implementation budget.

When migrating data to NetSuite, it’s important to determine which data to migrate and at what level of detail. You should consider what data is essential for your business operations and what data can be left behind. It’s important to strike a balance between migrating too much data, which can be expensive and time-consuming, and not enough data, limiting your ability to use NetSuite effectively.

 

2. Assess the source data quality

We recommend conducting a data audit in advance of your NetSuite migration to get an idea of what’s possible. Quite often finance teams will know how good or bad the underlying quality of its data is so the audit can be completed via questionnaire. Once the finance users start to get an understanding of the data fields required as part of the migration, we can start to get a picture of any limitations.

Here are some key data objects that you will need to make an assessment on data quality and a decision about loading:

General Ledger Data – Do you want to load transactional-level data? This will result in a big increase in the time required for data migration. Depending on your business this may not be necessary but you will need to retain read-only access to your existing ledgers. In my experience, there are 3 options for loading GL data:

• Importing summary financial statements and open transactions only
• Importing sales/purchase history + summary financial statements and open transactions only
• Importing all detailed transactions

Customer Data – How robust is your customer data? Quite often you will be reliant on your sales team for your customer data and sales teams are often not the best data gatherers. Are contact details current and up to date? How do we define and identify inactive customer records?

Supplier Data – How robust is your supplier data? Do you have contact details? Where are payment details stored? Is there duplicate records that need cleansing?

If required we can start to take samples and look into the underlying data. The aim is to identify data requirements and allow you to properly plan your migration and avoid surprises once the implementation has started.

 

3. Decide on data sources

You will need to consider the best source for existing data objects. This may be your current ledgers or other sources such as HR databases, Salesforce or other CRMs, expense tools or even bank accounts.  If these platforms sit outside finance, it is important to engage with any non-finance teams early in the project to make sure obtaining these data schedules does not impact the project timeline. Likewise, if any data remediation is required it should be agreed in advance where the responsibility for this will sit.

 

4. Decide on the data you will import

We like to use the following matrix to help our decision-making about migrating specific data objects and fields. This maps how necessary the data is – any required fields are ranked 10 – against the cleansing activities required.

Customer names for example are required and need little cleansing so should be quite straightforward to migrate. Prior Year TB may or may not be necessary and requires minimal cleansing so would make sense to migrate. It is useful to have customer emails in NetSuite, but the data requires significant cleansing so an assessment of options is required here.

Obviously, any required data will need to be loaded. If the source data is poor quality, then consideration is required around what the minimum standard required. How much time would be required to get it to minimum state versus a desirable state? How much time will this take? How will this impact project deliverables? Potential outcomes might be to cleanse the data and load accurate email addresses or else to load uncleansed data with the intention to remedy post-go-live.

 

5. Decide on a data migration strategy

Once you’ve decided on the data that will be migrated and the best source, it is time to outline a plan for the actual migration. You will need to decide who will be responsible for the various data extractions cleansing and loading. Here is a list of example considerations:

• What source ledger reports will be used to export data? Will you require new reports in your legacy ledgers to give you as much data as possible?
• Do these reports provide enough information, or will additional data need to be added from other systems?
• What volume of data needs to be migrated, and how will this impact timelines?
• What level of data cleansing is required? Do we have resources and contingency built into this? What sign-offs are required?
• Where data is required from other systems, is the system owner aware of the plan and has the data quality been assessed?
• Who will be responsible for data mapping? Is there a resource in the team to review and sign off on data mapping?
• What testing if any will be carried out to validate data migration activities?

 

Once this is all agreed you will have a clear path forward to complete data migration activities into NetSuite. These steps will apply to other systems, however, the strategy will be quite different in larger organisations mainly due to the volume and risks involved.

 

If your organisation is considering investing in an ERP or if you are planning your NetSuite implementation, then we can help so get in touch for a free conversation. Equally, we can help with any specific questions on data migration.