In this small article we give you highlights on how to move Microsoft Great Plains server to new more powerful hardware with minimal problems. Here we do not provide you information on GP version update, just how to redeploy.
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 dont 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.
Alba Spectrum Group, http://firstname.lastname@example.org 1-866-528-0577, 1-630-961-5918, serving Microsoft Dynamics GP locally in Houston, Dallas and Chicago metros as well as USA / Canada nationwide via remote support: California, New York, Florida, Arizona, Colorado, Wisconsin, Indiana, Georgia, Louisiana, Quebec, Ontario, Washington, Nevada, Virginia, Pennsylvania, Ohio, Iowa, Nebraska, North and South Dakota, Wyoming. Local service is available in Houston and Dallas areas: Rosenberg, Katy, Richmond, Galveston, Sugar Land, Aurora, Naperville, Wheaton, Plainfield, Romeoville, Joliet, Bolingbrook, Lombard, Downers Grove, Warrenville, Lisle, Montgomery, Oswego, DeKalb, Morris, Addison, Seneca, Ottawa. With reasonable travel we serve Springfield, Bloomington, Normal, Peoria, Sterling, Dixon, St. Luis, Peoria, Vandalia, Gary, Michigan City, Milwaukee.