Estimate for XE to 9.0 upgrade and platform change

[olsonbeast]

After searching previous posting, quest presentations and google, I decided it's time to post our situation here and see what the lords of jde can advise.

Have a look at the following, apologize for length but wanted to include all details:

Current situation:
- midsized city in Ontario (population around 90,000)
- on Xe since 2001 (SP23Q1) with everything including test/crp/prod on one iseries model 810 box plus one windows server for batch jobs
- about 20 fat clients, 80 thin clients via two windows 2003 citrix 4.5 presentation servers, no web client
- running Financials, HR, Payroll/Vertex, basic purchasing
- mostly vanilla, very little modification on JDE objects (maybe 5 to 10 small mods on programs)
- around 150 custom reports and 10 custom programs
- about 25 inbound and/or outbound Z table interfaces
- one man show for JDE administration - CNC, 2nd level business support, JDE projects, basic development work
- not currently using Websphere or OAS in our organization

Reason for platform change:
- current iseries running out of disk space necessitating either hardware upgrade or archive project
- get our organization in line with where Oracle is headed (better long term development/support for red stack versus blue stack)
- single source vendor
- our organization has been building a lot of Oracle DB expertise and gradually moving away from iseries
- want to implement high availability and better backup procedures, our iseries expertise here is lacking
- want to reduce iseries licensing costs

Reason for upgrade:
- access to new functionality including new HR modules and enhanced procurement and financials
- better reporting tools and easier end user access to data
- get prepared well in advance of 2013 sustaining support for XE

Where we think we want to go
- IBM system x platform, Linux OS, Oracle DB, OAS, Oracle Portal, IE browser
- version 9.0 or 9.01, whichever is most appropriate for a mid year 2010 implementation
- no new modules to begin with, add these on in a second phase (potentially requisition self serve, eRecruit, Employee self serve, depending on business case)
- unicode if necessary

Project assumptions:
- we get all the testing support we need from the business
- user training is outsourced
- day to day support of XE is backfilled leaving the current CNC/JDE adminstrator for full time project work
- Oracle DBA available 25% for project work
- Applications/data architect available 25% for project work

What I'm looking for:
- amount of technical consultant help required for planning/installation/upgrade
- amount of development consultant help required for recoding custom objects
- elapsed time of project
- any increased JDE support requirements going forward
- any major flaws in our plan

That's about all I can think of, just trying to get some real high level estimates so we can begin planning the pain. Thanks in advance, Kris Olson.

 

[altquark]

Hi Kris

Wow. You present an excellent argument for moving platform and moving to a later version of EnterpriseOne. Obviously you've done a lot of research, and this is definitely the correct mentality for preparing to upgrade.

Lets cover the bases as far as how the upgrade would work.

First of all, the biggest unknown in what you're stating as your current infrastructure is the interfaces - those 25 Z table interfaces probably have some sort of FTP or script-based interface routines, and those need to be investigated as far as the amount of time to recode those under a platform change. More than likely, the Z files they are looking at probably haven't changed much between Xe and 9.0 - so its just pure recoding. thats the unknown.

So what about the rest.

First of all, I'd strongly recommend performing a CNC Technical Audit. This will identify how your implementation meets the vanilla implementation standards, and identifies any challenges that might occur with the upgrade. Additional environments, pathcodes, wierd OCM mappings - these all impact how a successful upgrade occurs.

A technical audit usually takes a consultant no more than 2-3 weeks to complete and costs around $10,000 USD.

The next step is to perform an Upgrade Planning Workshop. This performs a feasibility study on the functional side of how you shall upgrade from OneWorld Xe to EnterpriseOne 9.0. Using the JDE "Compass" methodology, you'll initially cover the minimum technical requirements for EO 9.0 as well as cover the requirements from a staffing perspective - what power users time will be required, what functional consulting time will be required etc. There will be a number of deliverables that occur as a result of the upgrade planning workshop including a readiness survey (which actually comes as part of the technical audit) - the communication and training plan and the expectations.

As far as your upgrade timescales - well, you'll be creating a brand new instance separate from your AS/400 instance because of the platform change. This is a good situation since it provides a "sandbox" environment to perform the upgrade. So, after the technical requirements and planning has completed - and the hardware has been ordered and delivered - the time to install a fresh EnterpriseOne 9.0 instance is about 3-4 weeks of a technical consultant.

At that point, you are able to start the actual upgrade process where you can now map functionality across and identify what existing custom reports and functionality needs to be migrated. I suggest migrating existing functionality from Xe to 9.0 individually - only because it doesn't require the Xe environment to undergo a "code freeze" - and it gets away from those messy "spec merges". Boomerang is an example of migrating code between Xe and 9.0 (but there are other solutions).

Security will change, so from that perspective its important to identify the list of users and create a "closed door" environment. Roles and Task Views will then need to be created.

A big change for your users will be the interface. From that perspective, it is important to identify what is required to cross train the users from the Win32 interface you currently use to the new Web interface. Whether you continue to use Citrix to publish the web browser or not is based on whether you have users at remote locations (web performance) as well as whether you feel you can manage the web browser on the client machines. You will almost certainly remove all fat clients and the recommendation is to convert "fat client" functionality to the web or, as far as developers are concerned, to come up with some centralized solution (such as Virtual workstations).

ok - so now you have to understand how you are converting the data. This is not a difficult thing to do - Oneworld provides lots of tools that allow for migration from one platform to another. However, you have to perform the data migration and THEN the data upgrade within a set time limit (usually a weekend). So, from a CNC perspective, you have to develop OneWorld conversions to handle the data. Believe me, this isn't actually that difficult a step - it takes a good consultant very little time to convert the data from the AS/400 and for it to appear under Oracle - BUT you must TEST the data thoroughly.

And that leads into the User Acceptance Testing phase. This is certainly the largest "meat" of the upgrade project - and a MINIMUM of three data refreshes should occur prior to the actual go-live weekend. Users will fully test all of the functionality in the 9.0 system using set scripts that have been created, and each time the results are identified to ensure go-live success. "Scripts" include all the day-to-day processes as well as month ends, reporting etc etc.

I just completed an upgrade for a customer from Xe to 8.12 last year - about the same size as your implementation with a similar platform change (AS/400 to SQL Server). I spent about 8 months solidly on the project - but I wasn't only providing the technical assistance, I provided the functional assistance with "variable" backup from other resources as and when required.

Your worst case scenario would require :

Technical Audit ($10k) - 2-3 weeks for deliverable
Upgrade Planning Workshop (~$20k) 4-5 weeks for deliverable

6 months Technical Consulting including initial installation, upgrade processes, data migration, data conversion etc etc.
2-3 months in retrofitting (simple code changes) to 6 months of development (major code changes)
2-3 months of financials/reporting and purchasing (if VERY basic) functional assistance
3-6 months of HR/Payroll assistance (this is likely to be the biggest change since this has completely been re-written after Xe)

Total time of project - Could conceivably take 6 months from time of initial installation with 3 distinct "testing" periods prior to go-live. Each additional testing iteration extends this by at least a month.

Increased JDE support requirements include the technical aspect (Oracle DB, OAS etc etc) - but I cannot perceive any additional functional support requirements post go-live.

As for the flaws - there are probably many in my initial "stab" - but the success of the upgrade realistically depends on the amount of user commitment and buy-in.

Feel free to contact me directly to talk about this in more depth.

 

[mack211]

Jon,

That was a great write up. I am new to this forum, I wish I had found this site earlier. I am fairly new to the CNC world (started 1 year ago). I just finished a Xe to 8.12 upgrade. The biggest things that we had to deal with was issues with going to Unicode and how that affected 3 party tools. Custom tables created outside of E1 is another thing to look out for. + Sales Commission history conversion, F4211 custom field data load, etc. that we had to deal with.

If there is are any problems or questions that I could help with, I am more than willing.

-Mack

 

[olsonbeast]

Jon, this information is invaluable, thanks for taking the time - This will be a great help in putting our plan together. I'd never heard of Boomerang before, looks interesting. Also, never heard of JDE "Compass" methodology...any further information here?

 

[altquark]

Hee hee - I don't know how many people have heard of "Compass" methodology ! But if you've implemented EnterpriseOne/OneWorld - then you probably know something about compass methodology already.

Again, heres a bit of a history lesson in methodologies. After I finish, I'll turn the lights on by slapping them VERY loudly to wake you all up....

ok - Back in the day, JD Edwards moved from a custom-based developed computer system on System 38 to more of a packaged solution on AS/400 systems. During the early 90's - they were selling quite a number of their software packages, so they decided that they'd better create some sort of methodology to help customers implement.

Thus was born "REP" (no, not RIP) - standing for "Rapidly Ecomonically and Predictable" - this is the standard ancient methodology that all JDE ex-employees know - and where the terms "CRP" (Conference Room Pilot) stem from.

The REP methodology was simple :

Agree on Expectations -> Train -> Analyze -> CRP ->Tune/Develop/Test -> Go Live ->upgrade/audit

and thus it would rotate back to the beginning. Nice and simple.

Well, this client/server stuff came along - "Software for a changing world" - and in 1996 OneWorld was launched. The issue was that the methodology didn't specify anywhere how much technical input was required - and that meant that customers AND consultants went into OneWorld implementations "blind" to the impact of OneWorld on technology.

SO, the first "stab" at pushing technical requirements onto the existing REP methodology came about. Boxes were "slapped onto" the existing methodology diagrams - and terms such as "Technical Implementation Planning Session", "Technical Project Strategy Workshop", "CNC Implementation", "Tune CNC" appeared. However those pretty REP charts looked horrible with the technical tasks added onto them.

Denver decided in 1997/1998 to change their methodology and to also incorporate "Composer" - a new "rapid implementation" part of Oneworld that would populate configuration information based on a question/answer session. I was the technical input into this new methodology, based on the work I did incorporating the technical tasks I added to REP. The new methodology looked like this :

Define -> Train -> Model -> Configure -> Golive -> Refine

each of these headings rolled the project along and each had a number of tasks that had to be completed prior to the start of the next step.

This methodology changed its name a couple of times, but it was referred to as "One Methodology" mostly - and is the basis for most Oneworld Xe implementations.

Peoplesoft took over JDE in 2003 and headed into the "dark period" where there was a large amount of uncertainty about the Oracle takeover. During this time, many JDE functions were "mapped" over to existing Peoplesoft functions - including mapping to the implementation methodology.

Named "Compass" - this methodology had the following steps :

Strategize -> Plan -> Structure -> Construct -> Transition -> Deploy

Again, each of these had specific deliverables and tasks within each of the steps.

Finally, as we move towards more of a service orientated architecture (SOA), Oracle already has a new methodology for the implementation of SOA "aware" products called the "AIM" (Applications Implementation Methodology) Methodology :

Definition -> Operations Analysis -> Solution Design -> Build -> Transition -> Production

On top of this, your implementation partner will no doubt have their own flavor of implementation methodology. But is one methodology "better" than another ?

Not really. Projects don't succeed because of the type of methodology utilized - but they might fail if certain tasks and processes are missed - hence a standardized methodology with pre-built deliverables is an important choice when starting any project.

As you can see, each of the headings and tasks (when you drill down to each of these "methodologies") are very similar. They all provide relatively the same information at the end of the day - but certain templates match specifically to the type of product being implemented - hence the reason why there is a specific methodology for EnterpriseOne as opposed to using an "industry standard" implementation methodology.

End of history lesson - switching on the lights now !

 

[mmateus]

Hi Jon,

Thanks very much for that history lesson. It is very interesting and useful. We are thinking about doing exactly what Kris is planning to do so the information is very invaluable.

Thanks once again.

Kind regards,
Misael

JDE Administrator XE - SP23R, iSeries V5R4, Citrix 4.5

 

[FrancisR]

Hi Jon

Great article. I downloaded Compass from Oracle OPN and sent an email to Oracle to get the password in order to unzip the encrypted file, but I got no reply. Any ideas?

 

[markn8562]

Re: Estimate for XE to 9.0 upgrade

Hi Jon,

With regards to migrating from Xe to 9.0, do you have a guide (roadmap) for the steps to take? I am particularly interested in the steps needed on the functional side i.e. Inventory Management, Procurement, Sales Order Management and Advanced Pricing including testing with sample timelines

Any help would be appreciated. What would really help is a sample project plan with all the necessary tasks and time lines.

Thanks.
M

 

[DBohner-(db)]

RE: Estimate for XE to 9.0 upgrade

M,



Jon's gonna ask, too - how customized is your system?



(db)



From: [email protected] [mailto:[email protected]] On
Behalf Of markn8562
Sent: Tuesday, January 05, 2010 3:42 PM
To: [email protected]
Subject: Re: Estimate for XE to 9.0 upgrade



Hi Jon,

With regards to migrating from Xe to 9.0, do you have a guide (roadmap) for
the steps to take? I am particularly interested in the steps needed on the
functional side i.e. Inventory Management, Procurement, Sales Order
Management and Advanced Pricing including testing with sample timelines

Any help would be appreciated. What would really help is a sample project
plan with all the necessary tasks and time lines.

Thanks.
M

_____


The entire
JDELIST thread is available for viewing.


Looking for a job? Check out the Job
forum


This is the JDELIST EnterpriseOne Mailing List.
JDELIST is not affiliated with JDEdwardsR.

To unsubscribe from this list via email, Click
<mailto: [email protected]?Subject=Unsubscribe&Body=Sirs,

Pl
ease remove this address from the JDELIST EnterpriseOne M

 

[cdawes]

I've done projects for 5+ Canadian Municipalities.

You can contact me offline to arrange a meeting.

Colin

 

[Terry DeMoure]

If you have access to My Oracle Support, this document will also be very useful:

JD Edwards EnterpriseOne Upgrade Resource PLAN
[ID 745932.1]

PDF attached

 

[olsonbeast]

Great, thanks for that - it's an excellent resource!