Redeploying Great Plains Microsoft Dynamics GP on new Windows Server

Our approach will be to give you architecture understanding, so you could make your decision knowing the options and technical reasons.  You should be familiar with such concepts as Microsoft SQL Server and its versions: 7.0, 2000, 2005, ODBC connection specifics, GP customization and its architecture (if you have one), GP ReportWriter and Reports.DIC, Dynamics.set file (where you see all your GP products integrated into your GP installation), eConnect and Business Portal (if you deploy BP), Crystal Reports  and MS SQL Server Reporting Services (or SRS – again if you deploy CR or SRS)

• Risk minimization.  Begin with philosophy, not with technical side of it, especially if you in the reasonable beginning of your career as DB Administrator, IT specialist, GP programmer or consultant.  If you move and redeploy GP over the weekend and then on Monday users will not be able to use it and in this case business will stop its operations – then you will be forced to roll back to the old server and this will be a lesson for you – strategy and planning is required
• Windows Server Name and IP address.  Please, make you homework first and get awareness if you do or don’t have customizations: Microsoft Dexterity custom modules, SQL stored procedures (integrations, extensions to dex modifications, etc.), custom reporting – all these are candidates that original software developers hardcoded server names, IP address or placed these as parameters into setting files.  If you are not really supporting and not in contact with original programmers or reports designers – the safest approach would be keep the same server name and IP address for the new server box (yes, this is what you just read – rename the old server and mount the new Goliath hardware box on its place with the same name and IP)
• GP DB migration.  There are special scripts for transferring user logins and passwords on GP customer source.  This step is required and you have to follow the instructions (or you might be the one who is MS SQL Server DTS maestro – then you may feel comfortable to transfer security this way – in this article we assume you are normal IP person).  These scripts should capture logins on the old server and save them to the file.  Then on the new server you create the logins from the file and then grant access (via special scripts, not generically) for the users to the GP companies/databases
• Server Side Software.  Sometimes you have such annoying things as software installed on the old server, utilized by users in their daily operations: eConnect is good example.  eConnect might be used by Microsoft Great Plains modified logic, GP customization or such add-ons as Microsoft Great Plains Business Portal – check if you use Requisition Management, Order Management, Employee Self Service and BP HR modules, Electronic Document Delivery – to name a few modules of BP family.  If this is the case – you should be comfortable to face Business Portal redeployment, with possible BP customizations, integrations, custom logo, etc.
• FRx.  This is financial reporting software, typically in use by your top financial people: controllers, VP finance, etc., so treat it with respect.  FRx has sysdata folder, where all FRx settings should be stored.  However, this is not the end of the concerns – FRx publishes its reports either to FRx viewer or to the files (like into Excel worksheets), and in the case of printing to the file – output directory might be hardcoded – unpleasant result might be FRx bombing out
• Report Writer custom reports.  Chances are high that your GP users workstations deploy centralized reports – review your user-side dynamics.set and find where you have REPORTS.DIC placed.  If you have them on mapped drive or through UNC path – you have to build up the same shared folders on the new server
• Switching to new Windows domain. If you are changing such nice things as active directory and windows domain, then think about user profiles, where user mapped drives might be initialized, plus printers (printers might be superseded in GP and when you switch to new domain with new printers management – you may need printer setting re-haul, not a big problem – if you do not deploy such business critical printers as barcode labels printing, dot-matrix invoices. Etc.)

Even if you think that it is too complex, you have the option to invite professional GP consultant to help you and plus we believe that GP redeployment is a way easier that something like mainframe or Oracle Financial redeployment on the new UNIX server.