In this second post detailing my journey to switch from a Microsoft Dynamics GP consultant to an Acumatica consultant, I will share
My first data migration
As a Dynamics GP consultant, I did not do the actual data migrations. Since they are done entirely in SQL Server, this task was always handed off to an in-office consultant dedicated to back-end SQL work. But I was assured by my colleague/trainer, Melanie, that the tools in Acumatica empower every consultant to do his or her own data migration. While the process is necessarily detailed, it is by no means insurmountable, as I soon learned. Thanks to Skype, Melanie was with me for the entire 3-part process so the client’s data was never in any danger despite this being my first time. Recommendation #1: Be sure your data is not in danger—take a snapshot of your data before you start a data migration, which will allow you to restore the data if need be.
The first step is to ensure the data is formatted correctly for the import. I exported the data to Excel and made any necessary format changes. Recommendation #2: Export the empty fields from the screen that you want to import along with the other data. This will provide a base template and is great to hand to your client and have them fill in.
Next, under Melanie’s tutelage, I navigated to the Data Providers screen. This is the foundation of the import. The data provider is a form to create a provider for Acumatica to pull outside data into the software. Inside this screen I uploaded the file I would use for the data migration into Acumatica. Recommendation #3: Always click the Save button. Once the file was attached I had to make sure I chose the correct sheet inside my Excel file to map the appropriate data in the next step of the data migration.
The next step was a bit more complex as I started building on how this data was going to be read by Acumatica. The Import Scenario screen maps the specific field that your data will point to. On the Import Scenarios screen, I named and mapped the fields inside Acumatica back to my data spreadsheet. This screen can be tricky, but my colleague provided an import scenario script, which it made it visually clear how this script worked. The import scenario script I was given need to be tailored to fit my client’s import file. Looking at the window that this data was going to be imported into I was able to correctly map this data.
Now it was time for me to take that leap to the last step in the process of the data migration and use the Import by Scenario. As I opened my Import by Scenario screen and selected my import script, I was ready to see if my customer upload script was going to work. I prepared the file I created into this screen and then clicked import. The import started and within 10 seconds it stopped. I was not happy as an error message appeared telling me my zip code length was not right. I went back and revised my Excel spreadsheet and relinked it to my upload. I have since learned that I could have just made my change inside the Import by Scenario screen by saving my corrections to the data. After a few more rookie errors, I was able to successfully get all my customers imported into Acumatica. Recommendation #4: Be sure you understand all of the data fields and data structure before uploading the data. This was a great success for me, but I felt I achieved greatness when I added information to my vendor file and uploaded all my vendors in one shot without any errors.
It turns out that Melanie was right—using the Acumatica import tools for data migration beats handing my import off to some dedicated SQL programmer. Now, as my Acumatica experience has grown, I’m ready to train my first client on the software and field questions. More firsthand Acumatica experiences to come….
By Steve Ratner,
NexVue (now Net at Work) Information Systems, www.nexvue.com
Learn more about Acumatica.
Download the whitepaper, “Clearing the ERP Clouds.”