NetSuite Re-implementation
Have you ever been in a company where their current NetSuite system was so clattered they decided to purchase a fresh new account and migrate everything over? In this project, my client spent a whole year (plus $1m) writing new functional specs for custom functionality they wanted to move, in addition to training the new business process to users and performing data migration exercises. I thought it was worth mentioning this project because it may help fellow NetSuite enthusiasts working on anything similar.
Re-directing existing integrations
In our case, there were approximately 2-3 integration platforms we had to consider, but for any company re-directing their integrations to another NetSuite system, remember these high level steps:
• Firstly, write a functional specification for each integration you have in the business. Each specification should detail just about everything: related scripts, fields, custom records, architectural diagrams, as-is/to-be architecture. The worse thing you can do in any project is fail to document the work you are undertaking. Just imagine how difficult it becomes to diagnose future issues when you have nothing to refer back to!
• Secondly, determine the integration method for each integration platform. This is important as it will impact the way the external systems contact your NetSuite account. Undoubtedly, you will need to configure new authentication details for each of these. For security purposes, I would ensure each integration is using a 'Web Service Only' role to prevent unauthorised UI access.
• Thirdly, ensure each integration is configured with an Application ID. You may realise that an application ID is not a mandatory requirement but when you have multiple integrations attached to NetSuite, filtering the web service logs becomes problematic; especially when you trying to track down an issue for one specific integration.
• Firstly, write a functional specification for each integration you have in the business. Each specification should detail just about everything: related scripts, fields, custom records, architectural diagrams, as-is/to-be architecture. The worse thing you can do in any project is fail to document the work you are undertaking. Just imagine how difficult it becomes to diagnose future issues when you have nothing to refer back to!
• Secondly, determine the integration method for each integration platform. This is important as it will impact the way the external systems contact your NetSuite account. Undoubtedly, you will need to configure new authentication details for each of these. For security purposes, I would ensure each integration is using a 'Web Service Only' role to prevent unauthorised UI access.
• Thirdly, ensure each integration is configured with an Application ID. You may realise that an application ID is not a mandatory requirement but when you have multiple integrations attached to NetSuite, filtering the web service logs becomes problematic; especially when you trying to track down an issue for one specific integration.
Data migration
This is not the easiest of tasks to conduct; especially when you need to import records in a certain order. I recommend starting the migration exercise with the records that have 0% dependency on other records, then working your way through the hierarchical tree of records that cannot be created without the other.
• As a general rule, transactions cannot be created without entity or item records already on the system.
• When importing records, ensure to include an External ID so it can easily be referenced on another import files.
• Lastly, remember to switch the "SuiteScript" option on if any records can be created automatically (image below). This would cut out much time you would spend importing these records manually.
• As a general rule, transactions cannot be created without entity or item records already on the system.
• When importing records, ensure to include an External ID so it can easily be referenced on another import files.
• Lastly, remember to switch the "SuiteScript" option on if any records can be created automatically (image below). This would cut out much time you would spend importing these records manually.
Script migration
This activity can actually be tricky if the scripts are dependent on other records and saved searches on the system. I would recommend using the SuiteBundle feature to compile all scripts/fields/records in one installation package. Indeed, this will cut out much of the time you would spend creating script and deployment records but it does not come without problems:
• Internal IDs: any script that performs 'lookups' on records will require an internal ID. As the previous and new NetSuite accounts are different, the internal IDs used on the scripts will need to be updated.
• Overwriting scripts: Be very careful to not mistakenly update a script on the new NetSuite account. Make sure to use the SuiteBundle once to import the script over; if it requires additional updates, it may be better to update the script manually,
• Saved searches: Consider building any saved searches that rely on the inbuilt searches on the system within the script itself. This will reduce the risk of any 'record not found' errors throwing.
• Try/catch statements: the whole point of re-implementing a new NetSuite account is to streamline the system and make it more efficient. I highly recommend inputting try/catch statements around all functions that call an API. I.e. when creating a record, performing a search, submitting a record etc. Lowering the chances of errors throwing will enhance the experience for your business users.
• Internal IDs: any script that performs 'lookups' on records will require an internal ID. As the previous and new NetSuite accounts are different, the internal IDs used on the scripts will need to be updated.
• Overwriting scripts: Be very careful to not mistakenly update a script on the new NetSuite account. Make sure to use the SuiteBundle once to import the script over; if it requires additional updates, it may be better to update the script manually,
• Saved searches: Consider building any saved searches that rely on the inbuilt searches on the system within the script itself. This will reduce the risk of any 'record not found' errors throwing.
• Try/catch statements: the whole point of re-implementing a new NetSuite account is to streamline the system and make it more efficient. I highly recommend inputting try/catch statements around all functions that call an API. I.e. when creating a record, performing a search, submitting a record etc. Lowering the chances of errors throwing will enhance the experience for your business users.
New functionality
Businesses may wish to add new functionality to their new system, but factors like costs and time you have to train the users will need to be considered. My belief is if the new functionality is not business critical, save it for another iteration and allow your users to learn the new system first.