Dynamics GP Updating to Version 2010 Case Sharing Notes

There were about seventeen production companies and five test copies.  There was also VBA script to export data from external database, form text file and launch Integration Manager in command line with parameters, specifying integration.  This script was deployed as Shortcut.  Plus, we had FRx Balance Sheet and P&L for each company with consolidated versions for the whole group, where some business entities were running another accounting platform and Excel worksheets were used in FRx reports.  Release 8.0 was running on SQL Server 2005 with database compatibility level set to 2000 (as it was probably migrated from SQL 2000 somewhere in the past).  Let’s move over to details:

1. Migration 8.0 -> 10.0 Service Pack 5.  Here we had first test migration, where we set in Dex.ini logs to be created.  One of the companies was created with direct Customers migration from QuickBooks and we did this job.  In order to migrate customers we imported them into Customer table in SQL 2005 Data Import Wizard.  It looks like GP uses Customer table (by creating it in upgrade scripts and then removing). Conversion stopped and we were able to catch the problem in Dex log file.  Our customer table was renamed and upgrade re-launched and all the companies were upgraded successfully without the need to do annoying data repair on SQL scripting level.  Performance considerations: company databases were relatively small (below one GB) but the upgrade time was about 20 minutes in average for each company and even the smallest one took about the same time

2. Final Step 10.0 SP5 -> 2010 SP1.  No issues at all, again each company consumed about 20 minutes.  Both steps smoothness was a surprise for us, as we did some custom SQL scripting.  For example we had template company database, which we loaded when new company was created.  Then we had to delete History, Open, Work and some of the master tables (preserving Chart of Accounts).  When you are doing such actions, you may expect the possibility of non-critical data inconsistency (which should not be a problem while you are exploiting the current version, but they might become an issue when you are conducting release update)

3. FRx.  Customer made a decision to try migration to Microsoft Management Reporter.  Version 8.0 was using FRx 6.7 Service Pack 5.  As FRx is likely the candidate to be replaced by MMR in a matter of few weeks or couple of months, we decided to try the same FRx release (6.7 SP5) to be deployed for Dynamics GP 2010/11.0, and the approach worked.  We are trying to be a bit conservative in deploying FRx in the new environment – we recommend to export Specification Set, install FRx with default setting, enter registration keys and then Import Specification Set.  This method worked fine, however it requires some overhead – you have to create each FRx company manually (we usually create the first one and then clone and rename its ID, name and System Settings: Dynamics db name stays, you just need to change Company database).  Our user workstations had Windows XP SP3 32 bit edition (so we were not exposed to FRx discussions of not being compatible with 64 bit Windows XP, Vista or Windows 7)

4. Some practical common sense advises.  We scheduled update to begin on Thursday late afternoon.  Test update finished on Friday, when system was frozen for new transactions and only open for reports and inquiries.  Then Dynamics and companies database backups were copied on the new server and our consultants initiated production update at 5AM in the Saturday morning.  Each step took four and the half hours and we installed GP 2010 user workstations in the client office Saturday afternoon.  We recommend our customers to schedule version update project to be initiated at the second half of the week – in this case we have weekend time to fix possible issues

5. FRx versus Microsoft Management Reporter.  Well, old good days FRx is still doing its job in generating Consolidated Financial Statements.  However it’s under laying technology is quite outdated.  For example Specification Sets are Microsoft Access Databases (where .frl extension might be misleading, by you can open this file with MS Access, assuming that you know its encryption password).  MMR naturally supports 64 bit Windows Server and Workstation (Vista, Windows 7, XP 64, plus you can deploy its client on Windows 2008 Server, including Small Business Server 2008 64 bit).  FRx seems to be also installable on these OS versions, but Microsoft doesn’t guarantee that and it doesn’t support these installs.  We are kind of in hesitation to recommend FRx to MMR conversion to each customer, as we do not usually like the software application with just one or two versions released.  We rather recommend test migration, try all your reports to be printed out in FRx and compared with printed out versions from Microsoft Management Reporter.  This approach has more chances to validate all the features you need in your Financial Reporting and if new reports design tool does the job (in this case Microsoft Management Reporter) – you are good to do switch in production environment

6. Integration Management Integrations. Some of them (SOP Transaction) were set to use eConnect adapter for IM 8.0.  Looks like version 8.0 IM eConnect adapter was using direct SQL user login and password, while in 2010 eConnect user workstation you have to deal with COM object interface

7. Report Writer Reports.  Be sure that you upgrade Reports.dic based modified reports – typically SOP Blank Invoice with your company logo.  It looks like MBS is concentrating on such new technologies as SSRS and Word Templates, so the 8.0 SOP reports should be compatible with 2010 (you can try either upgrade or just import reports from old Reports.dic)

8. For further information, please call us 1-866-304-3265 or email help@efaru.com