Moving from AS/400 to MSSQL - How did you make that decision?

[Wes_D]

Hi All,

First off, this post is not meant to start a flame war for IBM vs MS. Now that's out of the way...

We're in early stages of a project to upgrade, I use that term loosely here, from A7.3 and a few module in XE to E1 8.12 with tool set 8.97. As fate would have it, our lease on our AS/400 is coming up soon so we can entertain the possibility of moving to MSSQL. We currently have a few application running on the MS2005 platform so we have some exposure to software.

Having said that, if you moved to MSSQL from AS/400 or decided to stay on AS/400, what convinced you to pull the trigger? What were the decision factors (cost, finding work force to support your system , or lack there of)?

If you did move, what were the learning curves (re-training staff, cost of ownership)? Do you regret making the move? why or Why not?

Thanks

 

[altquark]

Are you kidding ? MySQL is the KING of databases fool...You should be dropping that microsoft stuff and going with a real database (just as soon as I figure out how to code an ERP system in PHP)....

ok, I'll calm down now (!)

I've migrated (I hate using the term "conversion" when it comes to databases - its too religious sounding) lots of companies from one database type to another - whether from SQL to Oracle, AS/400 to SQL or any combination therein !

I think I've got quite a few posts already on this subject (you might want to try searching my ID on here for certain database topics) - but the underlying factor in the decision to go with one database or platform over another is purely whether you have experience on that platform or not.

If your corporate strategy is Oracle, then it doesn't make sense to implement EnterpriseOne on SQL Server - and vice versa. The scalability and performance of all these database types are all relatively the same (it just takes good architecture to ensure performance and scalability) - so its really a matter of what comfort level internally you have with a specific technology.

The only mitigating reason for forcing you into a certain platform is if you're still running some World co-existence (and why would you be doing that so long after co-existence was dropped) - then obviously you still need an AS/400 as a platform.

One note, however, about UDB (Universal DB). There really aren't that many UDB users out there (I estimate <1% of the total OneWorld user base). As such, it might be a candidate for Oracle to drop in the future. HOWEVER, saying that, EnterpriseOne 9.0 is still fully committed to that plaform - so if it ever DOES get dropped it'll be 10 years from now ! So, its probably not something to be too worried about...!

I'd guess that these days, the "makeup" of EnterpriseOne CUSTOMERS are probably now 50% on SQL Server, 40% on AS/400, 9% on Oracle and 1% on UDB. However, there may be more individual USERS on Oracle than, say, SQL Server (since the larger customers implement Oracle and the smaller ones implement SQL).

So, to summarize - your corporate database strategy should be based on a combination of factors (cost, finding the work force to support the system, cost of ownership, application requirements) - and JDE's database requirements should fit within that strategy....(and not be too much of a driver for the strategy !)

 

[gregglarkin]

[ QUOTE ]
I'd guess that these days, the "makeup" of EnterpriseOne CUSTOMERS are probably now 50% on SQL Server, 40% on AS/400, 9% on Oracle and 1% on UDB. However, there may be more individual USERS on Oracle than, say, SQL Server (since the larger customers implement Oracle and the smaller ones implement SQL).

[/ QUOTE ]

Jon,

That quote is bit too broad. There are other reasons to use SQL for JDE if you are a large customer - cost. The licensing costs for SQL are substanstially cheaper than the Big Red One. Also the amount of database administration time for SQL is a fraction of the time spent maintaining Oracle. On average (this is our DBA manager's estimate), we can assign 40 or 50 MS SQL databases to a full time DBA. If we gave that same DBA Oracle databases, they would be down to 5 or 10. This is all based on the workload to maintain a healthy system. We support both here, and we get a lot more bang from the buck out of MS SQL.

Gregg

 

[DBohner-(db)]

Hey - and if you go with SQL over IBM/bOrgacle solutions... er... you get
Case Insensitivity!

Really - you go with what your staff knows how to use.

(db)

On Thu, May 22, 2008 at 8:05 AM, gregglarkin <[email protected]>
wrote:



--

 

[altquark]

[ QUOTE ]

That quote is bit too broad. There are other reasons to use SQL for JDE if you are a large customer - cost. The licensing costs for SQL are substanstially cheaper than the Big Red One. Also the amount of database administration time for SQL is a fraction of the time spent maintaining Oracle. On average (this is our DBA manager's estimate), we can assign 40 or 50 MS SQL databases to a full time DBA. If we gave that same DBA Oracle databases, they would be down to 5 or 10. This is all based on the workload to maintain a healthy system. We support both here, and we get a lot more bang from the buck out of MS SQL.


[/ QUOTE ]

Actually, Oracle and Microsoft - in a large environment (and when I'm talking "large" - I'm referring to large SINGLE INSTANCE environments - ie, many concurrent users) - oracles cost is actually more effective. I think you refer to that in your statement too.

On a company with lots of smaller instances - then Microsoft has an excellent model - and yes, management of lots of individual instances is a lot easier under microsoft compared to oracle.

Whenever I talk about "large customers" - remember (and I've stated this many times before) I'm referring to large SINGLE INSTANCES of OneWorld - ie, a single instance with 1000 concurrent users. Almost all of those type of implementations (not all, but a significant majority) are running on Oracle. None are running on SQL from what I understand (SQL 2000 was never scalable really to that level. However, SQL2005 is certainly more scalable - and we should see larger implementations start to push that concurrent user number).

One thing the web HAS given us, in Oneworld, is a better method of pooling connections - therefore we should see 8.1x users on SQL server really pushing the 1k concurrent user limit more often. With an Xe style environment - the issue started really becoming the number of physical connections. The memory on SQL2000 couldn't handle 10,000+ active ODBC connections easily.

However, I know I'm sometimes very generalistic, and do occasionally put out some broad statements. They're based on what customers I've seen - and I include your company in that list.

One day we'll get real numbers of the "makeup" of users from Oracle. I know someone, somewhere has a real list. They just don't want to release it !

 

[gregglarkin]

[quoteOn a company with lots of smaller instances - then Microsoft has an excellent model - and yes, management of lots of individual instances is a lot easier under microsoft compared to oracle.

Whenever I talk about "large customers" - remember (and I've stated this many times before) I'm referring to large SINGLE INSTANCES of OneWorld - ie, a single instance with 1000 concurrent users. Almost all of those type of implementations (not all, but a significant majority) are running on Oracle. None are running on SQL from what I understand

[/ QUOTE ]

Your point is accurate, large customers with single instances of JDE generally have a large unix multi-core server with and Oracle database for their enterprise server. However......

Most companies that large, who run a centralized IT shop, go with SAP for their ERP. As an example, two of our global competitors are Air Products and Air Liquide. Both companies sell the same products that we do, oxygen, nitrogen, hydrogen, and are roughly the same size. Both of them (and all of our other global competitors) run SAP with an Oracle database. We looked long and hard at SAP, but decided to stay with JDE and make the move to 8.12.

Why? Because we have a different IT model. Globally we have well over 10,000 JDE users. But we do not run a central IT organization. We keep our IT organizations regionalized and closely alligned with the business units that they support.

Gregg Larkin
North American JDE Systems Engineer
Praxair, Inc.

 

[altquark]

[ QUOTE ]
Most companies that large, who run a centralized IT shop, go with SAP for their ERP.

[/ QUOTE ]

Now who is over-generalizing ?!

Its true that SAP "owns" the Fortune 500 space - but that is due to the way that SAP was marketed into that space compared to JDE. SAP owns that space because there was nobody else there for the longest time. JDE OneWorld was the first offering that could scale into the largest companies - and it appeared late (1996) and really couldn't scale properly until 1999/2000 - and by then the entire market had been sewn up.

Case in point, when I did a manufacturing/replenishment benchmark for the "fortune 1" company in 1997 - the first time JDE and IBM actively marketed JDE to a large customer - we easily exceeded the requirements from the customer and demonstrated those requirements. The selection committee eliminated SAP and Oracle because they weren't able to demonstrate the functionality nor the benchmark (SAP didn't even bother to turn up), and therefore proposed JDE. Peoplesoft was eliminated early because it couldn't scale at all. When it hit the IT directors' desk, he ignored the report and proposed that Oracle was the solution (because he was a big Oracle fan). When it went to final selection, the board turned around and said "why would we go with Oracle when SAP is the biggest and we already own it ?" and SAP was chosen to be implemented. Cost difference ? Substantial. JDE was being positioned at 1/10th the overall cost of SAP.

So, how products are selected are strange and varied in the big guys. It was a cruel lesson to JDE - it cost almost $1m to run the benchmark (though it was used to close sales for various other large companies later on, including LaFarge and Honda).

 

[ebearman]

Wes,
I agree with altquark on how you analyze which platform to implement. I disagree with their statistical analysis for large versus small clients. I work with only one large (> 1000 users) client who is on a UNIX variant, the remainder run iSeries 595 boxes that scale incredibly high... I have numerous small clients (<100 users) that also run small iSeries systems in an 'all-in-one' configuration with WebSphere running in the same partition (they may only have one LPAR) as the enterprise server, all with good success.

That being said, I feel (and yes I said feel, not know) that Oracle is really putting their greatest efforts behind everything Oracle...

 

[pshearer]

Hi Wes,
The attached link is to a whitepaper I wrote for Microsoft on the AS/400 to SQL conversion process for OneWorld.

http://download.microsoft.com/download/8/6/7/867A7D31-5AAA-4C09-9DD7-E802459A0696/migrating_from_iseries_to_sql_server.pdf

For me the basic reason for moving is one of economics. The AS/400 is a good platform but an extremely expensive one. Considering you can get better overall up-time and performance from clustered SQL install and at lower cost, for me it’s a no-brainer.
Feel free to give me a yell if you would like to discuss further.

-Paul

 

[Wes_D]

Thanks Paul. We found you white paper a on the web, and if we do move to SQL, we're going it use it. Thanks again.

Wes

 

[Radjammin2]

[ QUOTE ]
Really - you go with what your staff knows how to use.

[/ QUOTE ]

This seems so simple but yet so true. Companies will discover a company standard but there seems to be no connection with this standard and employees. In the same breath why keep around mult DB systems when they do the same thing? Take a look around your shop, ask the SQL admins what they like to use and go with that, of course stay up to date to recieve vendor support, sry old DBA persons, I can't run an unsupport version no matter how much you like it.
At the end of the day, past cost, and deployment, maintenance at the SQL level is key. If you give them a new platform and a book, that's not using their existing knowledge effectively.

If you cycle though contractors at a high rate to manpower your DBA support, flip a coin and good luck.

 

[ondeh]

Hi Paul,

It was great, I can do direct "creative thingking" on reporting using SQL Server compare to DB2/400. Since my iSeries going stable application, my users all asking funniest report to be created which I could do it directly using Analyst Service or Crystal Report with Store Procedure in SQL Server. Now a days users are thinking far more than what we guest when we used "blue product".