Migrating 8.0 Flows to 9.0

Hello John Henley,
Thank you for replying to my post. I am refering WF things like tasks, user profile def and user category definitions. We have an install of 9.0 apps and there is no data copied over to process flow administrator. Surely Lawson does not intend for customers to rebuild all their data manually when they go from v8 apps to v9. I saw some information on WEBRUN and using PFI. Unfortunately we only have PF professional. I'm new to PF any input will be most appreciated.

That data is included in Lawson's 8-to-9 migration path. Lawson didn't leave it out. Who(m)ever did your migration didn't include it.

If the delivered Service Definitions, Forms, Objects etc did not get ported over, you can install one of the Solution packs and that will load those, but nothing you had custom. I would strongly do this if they are not there because if Form definitions and Objects are missing some delivered triggers will not work even if the Services are defined correctly and there is no diagnostics as to what the issue is, they simply just do not create a work unit.

You guys are a Godsend! Thank you so much for replying to my post. I hope one day I can reciprocate by sharing a tid bit of my Lawson experience with you.

I put the install instructions in the hands of my system admin contractor for the Process Flow Professions and Process Flow Solutions Apps 8x to Apps 9 migration. Now we need to load our data.

Anyone have any sucess stories on how you migrated your user data in the PF (logan WF tables) to version 9.0? We are considering using import db to load the user set up information; example WF tables such as WFUSERCAT and WFUSRPROFL. Aer there pitfalls with this approach?

When you did your Process Flow data migration, did you bring over transactional history?

Any input will be most appreciated!

joanna.bledsoe@jhsmh.org

The Lawson-provided migration utility will convert the configuration data as well as the transactions/workunits (there are a couple of options...off the top of my head, I can't remember them). So, you can use it to convert the flows, and the config data. Then you can start fresh with workunits, which is what most organizations try to do.

So after reading thru 5 pages on this thread.... Are you saying if we chose NOT to pay Lawson for their migration services, we're SOL when it comes to converting .FLO files to .XML files?

They must all be re-written from scratch?

If so, that sucks.

Well not really, but since you should be using a certified installer (i.e. Lawson or a partner) to do the migration , it should be included. The conversion utility is installed with LSF, it's the process of doing the conversion that is where you need the expertise.

Why should you use a certified installer? We have a large IT staff. The reason we did not use Lawson to do the migration was they would not SHOW or TEACH us how to do it. We wanted them to show us the first time, then they would do the other 11 conversions. (They are basically an ASP for 12 school districts). Lawson wanted to charge $$$ time 12 times, so we skipped using them. I'll ask the conversion programmer if they know anything about the utility and how I can use it (I'm one of the 12 districts), but we do our own PF, DS, etc.

The only reason is because Lawson stipulates it as a condition for providing support. Trust me, I'm not advocating their position.

"Awson offers a class to certify in the install that allows customers to self install. As far as converting fklows from .flo to .xml goes their is a perl script to do that and it is a simple to run. You may have to tweek some flows such as of you do AGS calls to RD30 but otherwise it is a simple process.

BTW - I found the PERL script and ran it with no problem. All of my .flo files converted and I'm now tweaking them as needed. It was MUCH easier than trying to rewrite them from scratch (and a whole lot cheaper than having Lawson do it).

I found that I had to tweek a number of my flows after the conversion. The Lawson conversion only took us part way. Some things that worked in 8 did not work as well in 9.

Also, we had a flow that looked at each associate to make sure that they had an active direct deposit record. (Ran great in 8.) Since upgrading to 9 it does not work. Lawson has not been able to find out why the flow will not work. The flow runs about half way through the associates and then the query stops working. (Some kind of SSO error).