experience with adding MSP6 to HR & GL suites?

Testing an MSP install can vary greatly; in my experience it's usually a 2-6 week effort, depending on the number of modules/suites as well as how many customizations. Things to watch out for: 1) any database changes introduced by the MSP, 2) any database customizations that need to be retrofitted during the MSP install process, 3) how many .scr (form) definitions Lawson changed via the MSP, etc.

Pay A LOT of attention to the install.log that gets created when the MSP is installed.

While It's not a MAJOR upgrade, but it can still be quite an ordeal.
One way to really figure out what needs to be tested is to look at the install.log that is created.

I agree with John. You should test thouroughly, after getting sign off from management/execs.

If you read the notes from the MSP you'll get an idea of what is being fixed or changed. Some of those fixes and changes may not impact your systems or operations directly depending on your company because you don't use that functionality, for example. But the "obvious" ones of course you should pay attention to.

-roger

Thanks for the heads up. In regards to your warnings,

1) database changes would be noted in the patch read me file, are we just ensuring that if a table or field was added that the database reflects the change?

2) we are fortunate not to have any customizations at this time, we are new to Lawson

3) What do we do about the .scr (form) definitions Lawson changed, do they require tweaking or eyeballing?

Sorry for so many juvenile questions, this is our first.

Database changes are important if you've designed any reports (e.g. Crystal) against the tables and/or if you've made customizations to the database itself (which it sounds like you've fortunately not done). Database changes should be noted in the read-me file, but they will definitely be obvious when you do the MSP install itself. If the MSP install does a 'dbreorg', you'll see what the database changes are. If you ever do make database changes, you'll actually need to use a different approach to the MSP install in order to re-introduce those changes. But that's an altogether separate topic which thankfully doesn't apply in your situation.

The screen changes are particularly important if Lawson changed the parameters screen for a batch job, and you have saved batch jobs (including recurring jobs). In those cases, the new screen definition no longer matches the parameters saved with the batch job, so those job definitions will need to be updated prior to running the batch jobs. This can be minor, or it can indeed be HUGE. In some (albeit rare) cases--including one I'm working on with a client right now--the screen definition changed and the client ran their old jobs and it resulted in corrupt data...

has anyone put in the MSP 4 for lawson version 9.0.1.5 (we are windows 2008 64 bit) and considering embarking upon the MSP. Any issues or gottcha's??

We have had particular difficulty with the Lawson interface jobs even while doing CTP patching, MSP's Environment updates, or the sending system (Cerner, ParExcellance, WITT, etc) have done upgrades or changes. Make sure that you test all of your interfaces extremely well!

We succeeded in upgrading 2 environments (test/dev) from 9.0.0.4 Env/Apps to 9.0.1.5 ENV/9.0.1.4 Apps (Aix5.3/Oracle10gr2).

Couldn't get launchpad.sh to work when installing WAS 6.1, I had to run the ./install instead.

Microfocus 64 bit netexpress install was somewhat tricky. We created a new install directory to not clobber the old 32 bit microfocus which one environment still uses.

Other than that, the install/config. phase was fine.

The users are starting to test, so the above comments will be on the radar screen. thanks for the heads up!