E9.2 Replatforming off of iSeries / IBM i

[MonsterCable]

We'd like to replatform off of our IBM i and move JD Edwards to a Windows platform.

Has anyone here undergone that journey? Any tips, tricks, gotchas, etc. that you can share?

We're very much in the discovery phase of this project but would like to start lining things up so we follow best practices, lessons learned, etc.

Any and all help would be appreciated! Thank you!

 

[Larry_Jones]

Are you upgrading at the same time?
From version To version?

 

[MonsterCable]

We're currently on 9.2.1.1 but we're planning on upgrading next year to 9.2.5.4 and depending how much of a mammoth this is, we'd like to leave it at that version for a little bit and do the replatfom.

 

[tblancett]

We made the "soft" decision to pursue this course of action a couple of years ago, and as of now we have a hard deadline of year end to completely migrate from our iSeries to a full Windows/MSSQL environment. One of the most helpful things we did early on (in 2019) was make the decision to stand up a Windows ES with our DV920 pathcode installed on it, and hook it in to our iSeries DB in addition to our iSeries ES. This allowed us to get a better understanding of how the "basic" windows side of things works compared to iSeries (job queues, JDE services, printing, fonts, 3rd party apps, etc etc etc). A lot of the decisions you're going to have to make in regards to "what's best for you" is generally strictly based on your organization needs and staffing. For example, one of the big hangups we had in our environment was that over the years (since we implemented Oneworld in the late 90's) was that we had grown incredibly reliant on iSeries CL/RPG programs to supplement our business processes. Having that windows enterprise server in place in dev allowed us to really test a lot of proof of concepts using that platform and implement platform agnostic processes, so that now the only step left is to migrate our business data to SQL. As a side/main note, we are planning on a migration within the same version/bitness (our iSeries platform is on 9.2.6.3 UN6, as is our newly minted Windows/SQL platform).

Again, I don't know if there is any true one size fits all approach, but that is what we did, and it has worked well for us thus far.

 

[MonsterCable]

We made the "soft" decision to pursue this course of action a couple of years ago, and as of now we have a hard deadline of year end to completely migrate from our iSeries to a full Windows/MSSQL environment. One of the most helpful things we did early on (in 2019) was make the decision to stand up a Windows ES with our DV920 pathcode installed on it, and hook it in to our iSeries DB in addition to our iSeries ES. This allowed us to get a better understanding of how the "basic" windows side of things works compared to iSeries (job queues, JDE services, printing, fonts, 3rd party apps, etc etc etc). A lot of the decisions you're going to have to make in regards to "what's best for you" is generally strictly based on your organization needs and staffing. For example, one of the big hangups we had in our environment was that over the years (since we implemented Oneworld in the late 90's) was that we had grown incredibly reliant on iSeries CL/RPG programs to supplement our business processes. Having that windows enterprise server in place in dev allowed us to really test a lot of proof of concepts using that platform and implement platform agnostic processes, so that now the only step left is to migrate our business data to SQL. As a side/main note, we are planning on a migration within the same version/bitness (our iSeries platform is on 9.2.6.3 UN6, as is our newly minted Windows/SQL platform).

Again, I don't know if there is any true one size fits all approach, but that is what we did, and it has worked well for us thus far.

Thank you, that's very helpful!

 

[glen7x]

We moved few customers from IBM i to Linux. Other than the CL programs and the way how file shares work, the major step is moving the data efficiently and within the cutover window. You could choose to use the inbuilt R98403 ($ effective) or a data replication tool that is realtime.