Every implementation comes with some uncertainty, but our job, at Fenwick Software, is to reduce uncertainty and risk as close as possible to zero. This uncertainty is often a massive obstacle for the people involved in a project, so it is important to ensure that sufficient time is spent at the start of the project to identify and analyse areas of uncertainty and risk, then take action to remove, or at least reduce, these and put contingency plans in place.
A couple of weeks ago I was involved in an upgrade of NAV, from NAV 2009 R2 to NAV 2013 R2 with a relatively low level of customisation, for a client working in the food industry. The difference between both versions of NAV is quite significant but the good thing was that the users were already working with the Role Tailored Client, making their new experience smoother. This meant we could pay more attention to the way the upgrade would actually progress.
On its website Microsoft recommends a series of steps to follow in order to upgrade from one NAV version to another. It provides the migration objects that will be needed to process the technical migration of the database. We had to include two extra steps: first, to keep all the customisations that had been made for the client and include them in a brand new NAV 2013 environment; second, to apply our latest Fenwick Gold granule and the Payroll package. It was essential, of course, to avoid any loss of data during the migration.
I used the recommended Microsoft migration approach as my base then built the additional steps around that to make sure that the client would not lose any existing functionality. This preparation and planning is critical and has to be reviewed several times, to ensure that there are no glitches on D-Day, and to accurately estimate the time and effort that will be needed for the upgrade.
Once we were confident we had a stable environment, and after running an advanced testing set, we installed a test database on the client’s server so they could get accustomed to it and spot any potential problems before Go-Live. On the Go-Live day the old database has to be isolated to prevent its use in order to start using the new environment with no loss of data.
In between is the data upgrade phase – always an area of risk. Everything went very smoothly as I just had to follow step by step what needed to be performed, and after a few hours, a functional database was created. The very last phase is to manage the permissions, which will give access to every user, not only to NAV but also to their own area of work. In an ERP like NAV, the information provided by the different tables can be used in multiple areas of the product and, without care, they can quickly become a maze for the administrator to allocate.
The secret of a successful implementation or upgrade lies mainly in the preparation time we can allocate to it. In any smooth implementation there is absolutely no room for improvisation, which is a source of stress that we can do without on a Go-Live day. Allowing sufficient time and thought to project preparation and groundwork always pays off.
