Protecting customer investing!

Upgrading to a newer version should be a strategy for many company’s’. Navision are spending around 40 Million $/Year and have around 100 developers working on the next version. Navision is also giving us some tools for upgrading, but it’s important that we early in the project have a strategy for making changes in Navision. For example: If you do a change in an IF-THEN-ELSE, and Navision also make a change in this logic at next version. Then you must redo the design work, and get a lot of work for upgrading. I think that the best way to do customer solution is as so long at possible leave Navision Logic and build it as Add-on. What’s you opinion about making changes in your customers solution and protecting their investment for future upgrading? Per.Bay@navigera.com Product Manager www.navigera.com

Per Bay, prior to becoming an end-user, I was an NSC employee for 5 years. In my experience, your question has not “easy” answer. Add-on type design usually lends itself to larger development projects. Sometimes, a very small project (add a new field to Item Ledger) can cause a change to be made to 2 different posting routines. For example, if I have a new field in the Item Ledger that needs to be populated from the Sales Line during posting, the Sales-Post and Item Jrn Post Line codeunits must have a new line of code inserted to transfer the value. You can try to limit the number of mods by putting calls to new codeunits. The good news is that with practice, the merge tool is pretty good with merging your mods into a new version of Navision. Aston Group in Indianapolis, IN USA has alot of practice with this. You might consider contacting them with questions. Bill Benefiel Manager of Information Systems Overhead Door Company billb@ohdindy.com (317) 842-7444 ext 117

William, thanks for you comment. I understand that this question has no “easy” answer. But I’m thing it’s worth a discussion. We have already skills in upgrading to newer version, the question is how you planning for making this process easy. Your example is a good description of a change that have to been done in std. objects by adding new field and new code for posting routines. And you don’t change any logic in Navision, You just adding new logic. Per.Bay@navigera.com Product Manager www.navigera.com Edited by - per bay on 2001 Jul 06 13:28:39

I try as far as possible to limit the changes to base Navision. Easier for upgrade path as your new tables etc: normally bolt straight on. As Bill says for the additions to work properly they must be intergrated with the base application at strategic points, so you have to trade off one against the other. I have seen in the past horrors like 20 additional fields to a Sales Header to hold Information that could have been stored in a secondary linked table, with a bit of thought and normalisation. David Cox MindSource (UK) Limited Navision Solutions Partner Email: david@mindsource.co.uk Web: www.mindsource.co.uk

When I first had to upgrade a heavily customized solution from 1.1 to 1.3 it took about three weeks. The third and last upgrade of the same solution to 2.60 took about 12 hours! (337 objects) So what’s the secret, you ask? There are three things to consider: 1) documentation 2) documentation and 3) documentation! The very first version was only badly documented (no, it wasn’t me). But during the upgrade I documented every change and this paied off in the second and third upgrade. A visually small change like from MODIFY (FALSE) to MODIFY (TRUE) can have an important impact on the program. If you forget to document this change you will spend hours to find out why the routine doesn’t work anymore. Documentation does not only cover changes in C/SIDE code but also changed properties and added fields, keys and SumIndexFields. The technique how to document has been discussed already intensively so I skip this part. It is important, that all changes have a common and unique part of the version number. Such as IBM01-nn where IBM01 is the unique part and -nn is a running version number. To do the change, you simply export the modified objects of the old version to a text file and then do a search on the unique part //IBM01 and you will easily find all changes. While it is correct that whenever possible, customer code should be put in a separate codeunit, I don’t see a necessity for doing so in every case. Let’s take the example from Bill about an added field to the item table which has to migrate to Item Jrn Post Line. In cu80 you can call an external codeunit which transfers the new fields into the Item Jrn post line:

//IBM01
cuAddFields.ToJrnPostLine(... parms);

Alternatively you can transfer the fields directly:

ItemJrnPostLine.NewField1 := NewField1;
ItemJrnPostLine.NewField2 := NewField2;
ItemJrnPostLine.NewField3 := NewField3;
ItemJrnPostLine.NewField4 := NewField4;

The problem in both cases is that you have to find this place in cu80. You wouldn’t without the documentation! Once you found it, it’s irrelevant whether you copy one or four lines to the new cu80. Second advise Before you start with the upgrade, make sure you understood all improvements of the new version. Take as example the Number series which have been introduced in version (not sure!?) 1.3. So every “get-next-higher-number” code in your old 1.2 version had to be adapted to the new Number-Management function. Third advise The compiler is your friend! Most rooky programmers are happy enough if the compiler compiles an object without errors. But that’s not the target. The target is to have all customer specific changes integrated seemlessly into the new version, using the new functionality. Example like above, the change in NumSeries: Providing you had in the old version a Key-Field which should increment a PK code field in a customer table. You would have designed MyKey copying the old increment functions as they were used for Sales Invoice numbers and the like and have this field placed in an appropriate Setup table. For the new version (with NumSeries) you could leave this field in your setup table like it was and the compiler would not complain. However, you should adapt the logic to NumSeries and therefore simply delete the old MyKey and insert instead a new MyNumSeries field in your setup table. Having done so, you only need to do an attempt to compile all objects and you will easily find the ones who failed to learn where MyKey has been used. Fourth advise Test often: You test, it works. You change something, test again, it doesn’t work. Conclusion your change is wrong. You do 6 changes before you test again and you won’t know, which of the 6 changes causes the problem. — Hope this helps ------- With best regards from Switzerland Edited by - fabian on 2001 Jun 30 03:24:32

quote:


Originally posted by fabian: When I first had to upgrade a heavily customized solution from 1.1 to 1.3 it took about three weeks. The third and last upgrade of the same solution to 2.60 took about 12 hours! (337 objects)


Hi Marcus! I have the same experience like you. I remember my first upgrade I done in 1998 and I think it took about 2 weeks. Today can we do an upgrade from ver. 2.00 to ver. 2.60 in 1-2 days. I think this is because: Better Tools, Experience, Better documentation, Good strategy and soon…. I will also remember a couple of upgrade from 1.30 to 2.00 where we have customer changes that were changing Navision business logic in sales line and some more places. That was giving us some trouble with all new logic Navision was changing and adding. We hade to redo a lot of work. (Merging didn’t work very well ). I think we will have the same problem when upgrading to Attain if we have make some change in Navision logic and they also have made changes.

quote:


Originally posted by Cox: I try as far as possible to limit the changes to base Navision.


I agree with David. Per.Bay@navigera.com Product Manager www.navigera.com Edited by - per bay on 2001 Jul 03 23:29:12