Like many businesses running JD Edwards, you may be interested in upgrading to the latest version and moving to the cloud. What should your JDE project plan look like for these two projects? ERP Suites cloud experts are on hand to answer the common questions that arise when planning to upgrade JDE and migrate to the cloud.
Combined Projects vs Separate Projects
Question: Would it be better to upgrade JD Edwards first and then migrate to the cloud, or migrate first and then upgrade?
Answer: When creating a JDE upgrade project plan, we generally believe the best practice is for companies to combine the projects together: migrate to the cloud and upgrade JD Edwards simultaneously. If you look at everything involved with migrating JD Edwards from, say, your on-site data center to the cloud, versus doing an upgrade, about 70-80% of those projects will end up overlapping with one another. For this reason, if you combine them, you can achieve about 70-80% efficiency on the overall project.
While this is what we generally recommend, a few situations could arise that would warrant a different plan. For instance, we once had a customer that had lost track of their data center lease and suddenly discovered that they had a mere month in which to complete the migration before the lease terminated. In that case, they wanted to optimize for ‘speed’, since this customer was going to AWS, we utilized an AWS product called CloudEndure to perform continuous block replication, which copied the data from this customer’s on-premises servers to AWS. From this, we were able to take a point-in-time snapshot and stand it up as a test environment. The customer was then able to get in and verify that everything was working, and they could execute their business processes, and we were then able to go live. This was a rather extreme situation given the ridiculously short amount of time they had in which to perform their migration, but it serves as an example of a scenario in which a simultaneous upgrade and migration is not feasible.
Question: What sort of issues should we expect to arise during a simultaneous upgrade and migration?
Answer: No matter whether you’re doing a simultaneous upgrade and migration, or you separate them out, the most significant issue you’re going to run into is not so much with EnterpriseOne itself, but rather with everything surrounding it and integrating back into it. Ninety-nine percent of the time, JDE will work just fine. But let’s say you have some type of interface that has a hard-coded IP address. Well, with a cloud migration your IP addresses are most likely going to change. As a result, this type of interface will no longer work. For that reason, when you’re doing these migrations, you really need to test everything, and the testing is the expensive part from a business standpoint. It’s also why combining the JDE upgrade and JDE migration together makes so much sense. You only want to ask the business to test once.
Migration Downtime
Question: What sort of downtime are we looking at in a combined upgrade and migration?
Answer: Ultimately, the amount of downtime involved will come down to a business decision. Are you able to take a weekend outage, or is the impact of an outage so high it needs to be kept at a minimum? Generally, most customers will fall into one of two models:
Model One: Weekend Project
Around 75% of our customers will tell us that we can have an entire weekend for the project, or perhaps longer, such as during a Memorial Day weekend when users will be off the system for an extra day—giving us three full days to do the migration. By this point, you’ve already built and upgraded your new JD Edwards system on the cloud, and you’ve already been testing it in what will be your new production environment. In this scenario, you’re generally going to bring your business data over from your on-premises system and land it in the cloud, and you’re going to run through the upgrade process (say, from 9.0 into the 9.2 format, or from 8.12 to 9.2), update all your tables, and then release the system. For most customers, this sort of two or three-day outage to get everything done is very easy, very doable, and very inexpensive.
Model Two: Continuous Replication
The remaining 25% of our customers are companies that have 24/7 operations and will lose literally hundreds of thousands of dollars for every hour that they’re down. Naturally, we’re not going to suggest that these customers take their systems down for two or three days. In these instances, we will have continuous replication running on the database; and this is true even if they’re on an IBMI. You’re going to have to move it out of this IBMi db2 format, getting it into SQL server or Oracle Database, depending on what your target is for landing it. We use a third-party tool to do that: either GoldenGate or StarQuest SQDR. The really good thing about these products is that they provide for continuous data capture, so as things are changed over on the source system, they’re being asynchronously replicated on the target system. This means that your target system on the cloud is just a couple minutes behind what’s actually in production. When we do the cloud migration, we shut down the systems, give them a few minutes to finish replicating anything that might be in flight, and then, if this is on an older version of JD Edwards, we go ahead and do the upgrade. So, the entire movement of the data across the WAN to the cloud is taken out of the outage window. The outage is only needed to do the upgrade, get the system back online, and test everything.
Another possible scenario not involving anything as exotic as IBMI to Oracle or DB2 is simply moving from one Oracle database to another Oracle database. In that case, we’ll use DataGuard, or, if the target is AWS, we may go back and use the CloudEndure tool mentioned previously. If it’s SQL server, we’ll just do native SQL server replication over to the target. This is called Log Shipping. We take a full backup of the database about two days prior to go-live and restore it onto the source system. Then, one day before go-live, we’ll take an incremental backup and bring it over and restore it on the target system. Finally, during the outage, we’ll do a transaction log backup to pick up the last few transactions that have occurred and bring them over and apply them. In this scenario, the transport of the data itself takes only 30 minutes, and then we’re left with just upgrading the data itself.
End User Factors
Question: What sort of changes can users expect following a migration to the cloud?
Answer: Typically, for the end user, all the changes they’ll see have nothing to do with the cloud itself. There used to be an old t-shirt that read: “What if I told you the cloud is just someone else’s computer?” Literally, in the case of these legacy Enterprise applications, the cloud really is just someone else’s computer; we’re not talking about modern applications here. So, there’s nothing inherently on the cloud side that is going to change things for the user. Where they’re going to see a difference is in the JD Edwards upgrade itself. Let’s say they’re on 8.12 and upgrading to 9.2 with the 9.26 Tools series. The user interface is going to be different; it will still be familiar but getting into the app will be a bit different. Or, maybe they’re in XE, running in a Citrix environment, and now, suddenly, they’re going from Citrix to Web. That’s going to make a pretty big impact on how the users interact with the system. This really doesn’t have anything to do with the cloud, though; you’d see the exact same thing if you did the upgrade on-premises.
Question: Would additional training be required?
Answer: This will depend on how far you’re going with the upgrade and how sophisticated your user community is, and these factors vary widely from company to company. For example, if your organization is already on 9.0 and is jumping up to 9.2, very minimal training would be required. Your users will pick it up quickly and will probably be upset with you for making them do some form of mandatory training—although you should probably mandate the training anyway. With the XE and Citrix scenario mentioned before, a lot more training would be required.
Public Cloud FAQs
Question: Based on your experience with these combined upgrades and migrations, is there anything you can think of that companies were not aware of going into the process that, afterward, they wished they had known?
Answer: Three main issues stand out for us here, and all relate to the public cloud.
Database Licensing
The first has to do with database licensing restrictions. For instance, if you have an Oracle database, and it’s licensed by processor, what constitutes a ‘processor’ for the point of license definition, differs based on the cloud you’re deploying it in. The main thing to be aware of here is that the list price on an Oracle database is $47,500 per processor. They have something called the x86 core factor, which says that one processor license covers two cores; but they also built-in included language that basically says, ‘except if you put it on our competitor’s cloud,’ in which case it only covers one core. Microsoft does something similar with the Hybrid Cloud Benefit in terms of how you can bring SQL over and what the restrictions are with bringing SQL licensing over.
For these reasons, the most important thing to understand here is what your database is and how licensing is impacted in the cloud. Notice that this has nothing to do with technical considerations: we’re not talking about stability, resiliency, how fast the cloud is, whether it’s going to perform better, or any other such matters. We’re only talking about dollars and licensing agreements. So, make sure you understand database licensing stipulations on the cloud you’re deploying in.
Now, for JD Edwards itself, the good news is that, for about 90% of customers, one of the following two things will apply: licensing will either be based on the number of named users, or they will have a revenue license metric. In either of those scenarios, there’s no CPU involved, so the cloud you’re deploying into really doesn’t matter. You can do AWS, Azure, or OCI, or even GPC for that matter.
Application Hosting
The second thing to understand about this is that you need to know what you have talking to your JD Edwards system. Let’s say you’re using a barcoding application that interfaces with JDE. That application most likely is negatively affected by latency, so if you leave your barcoding system on-premises, and it’s communicating across the WAN to your JD Edwards systems in the cloud, your users are going to experience performance issues. The same thing will be true of a lot of third-party software that integrates back into JD Edwards. Your best practice is to co-locate as much of this around JD Edwards as you can.
Data Egress Charges
The third issue here relates back to where these systems are sitting, and that has to do with egress charges: something we jokingly refer to as the ‘exit tax.’ If you send data into the cloud, it’s free; if you want to take data back out of the cloud, however, you’re going to pay through the nose, at least on some of the clouds. This makes sense when you think about it in terms of the cloud’s business model: they want you to move everything into the cloud as an incentive to avoid those egress charges. If you want to think of this as a carrot-and-stick approach, this is one of their sticks. So, you’ll need to understand what those egress charges are and what sort of volume you’ll have coming out of that system. A very common scenario is where you have a data warehouse—let’s say either on-premises or in another cloud—and you’ve decided that you want to put your JD Edwards system in AWS, but you’re currently using Oracle’s Autonomous Data Warehouse and you’re wanting to do ETLs from JD Edwards into OCI. AWS will charge you for all that traffic going from AWS to OCI. It’s free on the OCI side, but it can be very expensive depending on how much data you’re pushing out of JD Edwards into that Data Warehouse.
Question: Would normal operations within JD Edwards be subject to an egress charge?
Answer: No. They have a concept called VPC: Virtual Private Cloud. Anything within your VPC—that is, within your availability zone—is simply normal network communication and not subject to an egress charge. Where you get charged is with anything leaving your VPC.
Question: So, we’re not going to get hit with an egress charge for running a simple report?
Answer. No. Otherwise, those couple users who invariably delete their data selection and leave things wide open would bankrupt your company! It’s not that scenario at all.
When it comes to JD Edwards, ERP Suites is a trusted consultant with expertise in JDE upgrade best practices and migrating to the cloud. We can answer all of your questions about your next JDE upgrade and what cloud is best for you. We are continuing to invest resources in a future with JDE so you can continue your business success.
