This is the last post in the upgrade series that is specifically about "knowing your environment". After this, I will branch out into other topics but for now, I am doing a catch-all of smaller things I may not have noted in prior posts.
Posts in the series
- Series intro
- Process overview
- Know your environment (part 1)
- Know your environment (part 2)
- Know your environment (part 3)
- Know your environment (part 4)
- Know your environment (part 5)
Workstations & Users
Some questions to ask when planning for the upgrade are things like:
- Are all workstations installed identically? Does every machine have the same ISV products and modules installed on it? If not, make note of the exceptions to install the new version of Dynamics GP. I recommend a list of users and what they have installed, in groups if possible.
- Do any workstations have special settings, like dex.ini flags that aren't on the default install?
- Is Account Level Security or Field Level Security enabled/used in Dynamics GP? This one is purely for flagging that some of it may need testing.
Company Level Configuration
Some questions relating to the configuration I would want to know are:
- What modules have pathnames in the configuration? EFT, SafePay, and Electronic Bank Rec are a few off the top of my head that have pathnames in them, that may need updating for testing or after the live upgrade.
- Do users have shortcuts to external things like URLs to applications or reporting tools? Often if they do there is a way to script the changes for the "common" shortcuts. At a client of mine, many users bookmarked the SSRS reports URL in the shortcut bar. It was a relatively easy SQL script to mass update the path to the new server after the upgrade.
- Are there macros in place that are regularly used? If so, macros may need updating and/or the file location of the macro may need to be changed (if a shortcut was pointing to it for instance).
- Are there any SmartLists with Export Solutions configured? Will the paths to the Excel workbook/macro need to be updated after going live?
I have left customizations for the end, as there are few broad statements I can make about what to look for. In general terms, I would look at every upgrade as an opportunity to revisit why I have a customization in the first place, and if there is a better way to handle whatever it does. Sometimes clients customize things that eventually functionality is added for, and sometimes there is an ISV product that does a lot of what is needed and is less hassle than upgrading custom code every few years.
Otherwise, with customizations, make sure the source code is available (or access to whoever wrote it) in case changes are required. Most upgrades have table changes of some sort and often that may be enough to break a customization. Anything customized needs to be thoroughly tested during the test phase of the upgrade and time allowed for potential re-development of it in extreme cases.
Well, that's the end of this sub-section on getting to know your environment. The remaining parts of the upgrade series will be focused on testing itself and other "gotchas" I have to share.