You have undertaken an ERP cloud migration project to migrate your enterprise planning (ERP) systems to the cloud. At least, that was your intention.
Forget supernatural slasher horrors … those are tame compared to this nightmare scenario (at least if you’re an IT professional!):
Unfortunately, your new, virtualized servers, network, and storage don’t seem to be cooperating with your ERP applications. You rush around and manage to get that snafu worked out, only to realize that the peripheral systems and portals connected to your ERP applications, aren’t. Aren’t connected, that is. Another mad rush, and you bridge those gaps. Now all the systems are talking to each other! Right? Well, yes, but at a snail’s pace. Response times plummet, and critical operations start to tank, one after the other …
Yep, that’s a nightmare that will leave you drenched in sweat and shaking in your boots if IT is your business. The problem is, this nightmare can become a reality – unless you take some very practical steps to prevent it.
Let’s set the stage here. Obviously, more and more companies are thinking about a cloud strategy: what to move to cloud, where to move, when to move, how much cost savings are involved, etc. Cloud just makes good sense in many cases, with the majority of technology product and service vendors offering pay-as-you-go solutions in every conceivable area: servers, storage, network, software, platforms, applications, collaboration and productivity tools … you name it, and you can virtualize it.
This journey to the cloud definitely includes ERP applications which support major business processes, i.e., concept-to-production, order-to-cash, procure-to-pay, book-to-account, account-to-report, hire-to-employ, and more. Over the past few years, I have spent a significant amount of time with customers in various industry sectors like manufacturing, financial services, and healthcare, working with them to build a realistic pathway to align their ERP applications with various cloud computing environments. I’ve seen a lot along the way, which I have codified into “The Big 5” when it comes to migrating ERP to the cloud:
5 Tips For Avoiding An ERP Cloud Migration Horror
1. Pay by the drink … don’t buy the bar! Large ERP software licensing (i.e., Oracle, SAP) is a significant cost item in any IT budget. A meaningful ERP migration to the cloud needs to reflect saving by shifting ERP applications in whole or in part to a pay-by-drink licensing model in the cloud environment. Be sure to consult your ERP vendor(s) upfront regarding license-related cost-saving potentials in the cloud.
2. Stabilize the building if you want to move the foundation. Cloud migration of your infrastructure (server, storage, and network) has the potential to disrupt how your ERP applications will run. I’ve seen it frequently: a business is told, “Redirect your IP address and URL and all your ERP applications will run just fine!” In reality, running an ERP on the cloud is not that straightforward. You will need to carefully examine the various workflows which drive the successful running of the ERP (and, along with it, the day-to-day business) to avoid instability after implementation.
3. Don’t wreck the spider web. Picture your ERP system as the center of a spider’s web. Now envision all that radiates out from that central point: the peripheral systems the ERP interfaces with, the portals developed for collaborations with external business partners, the customized user interfaces, the reports drawn from the data … everything is connected and interconnected in a delicate framework. Your cloud migration needs to take into account this entire spider web that surrounds your ERP applications. For example, on one occasion, I was called in when a shipping system interface with an ERP Inventory Management system stopped working due to UNIX compatibility issues.
4. Don’t assume that you can “lift and shift.” I have seen this frequently: IT will “lift and shift” their entire server stack and the associated applications without considering the impact of bandwidth, criticality of data response time, security of the information, or local laws of the land before moving systems, applications, and data to the cloud. In one case, advanced pricing functions and the associated data in an ERP environment was barred from moving outside the company’s premises since the customer was very sensitive about security for that aspect of the organization.
5. Decide what to keep and what to change. Before migrating ERP applications to the cloud, an ardent effort should be made to determine whether upgrading or replacing some of the systems, functionalities, and customizations might make sense. It will mean more effort, but can result in significant business value. For example, when working with one customer, my assessment team found that the in-house ERP had interfaced with a Windows system for Internet-based procurement. We suggested that an upgrade to the latest i-procurement system in the cloud would eliminate the need for a third-party boundary system, remove a number of customizations, provide the company with a better total cost of ownership (TCO), and support more business functions. Once the company executives realized the return on investment (ROI) of this upgrade, they decided to switch to the new functionality in conjunction with the cloud migration.
And, yes: test rigorously before and after your ERP cloud migration to make sure you’ve covered all the bases. Your tests should include the critical business functions in the ERP as well as the peripheral systems and any collaborative functions with external trading partners. But don’t worry – if you follow “The Big 5,” you won’t experience a “Nightmare on ERP Street” when you test or when you go live. Pleasant dreams!
Related Business Solutions: Cloud Services