It’s Not Just an Upgrade
The “It’s Just an Upgrade” Myth
There’s a common discussion between technology vendors and clients on legacy systems. It’s about the upgrade path. Sometimes the client is on an aging system and kicking the tires on the notion of software improvements. Sometimes vendor is looking to convert a client on an on-premise licensing with low maintenance fees to a higher margin subscription. Eventually, these conversations end up in a similar place where the vendor is detailing the benefits of the latest and greatest. Then the inevitable happens. At The Confluencial we talk to clients about it all the time. Someone selling technology tries to convince them that “it’s just an upgrade” and switching from a legacy platform to the newest cloud technology will be easy.
But it’s not just an upgrade. It’s a new implementation. Make no mistake. This doesn’t happen in just ERP – it happens in CRM, MES, WMS, and just about any technology platform. How many times have you heard someone tell you that “you just need to adopt AI, it’ll be easy.”
This line of thinking gets at the heart of why this falsehood is perpetuated. It’ll be easy. One of the most significant barriers to any implementation of technology is the status quo. The easiest path for software? Doing nothing at all. The next easiest? An upgrade. That’s where the challenge comes in. Transitions to modern technology are major implementations no matter how you look at it and that makes them hard, which makes them risky. Hard and risky means expensive. So vendors, system integrators, and value-added resellers want you to believe they’re upgrades because upgrades are easy, not risky, and inexpensive. The harder they sound, the more risk there is to them making a sale.
As we explore this topic, we’ll talk about why these transitions to modern technology are so complex – and how they impact confluences in technology, strategy, people, and process.
The Technology Confluence in Modernization
We’ll assess three case studies in our discussion about why it’s not just an upgrade. The first is rooted in the transition from an on-premise solution to a cloud-based solution using Microsoft Dynamics 365 as an example. The second is the dependence on a single software for the core functions of the business using SAP S/4HANA as an example. Lastly we’ll discuss the functionality consequences of migrating from one software to another using Oracle ERP Cloud as our case study. All are good products in their own rights, but are also good examples of how you can spot a difficult implementation lurking behind an easy upgrade.
Software Packages are Rewritten for the Cloud – Microsoft Dynamics
One of the core reasons it’s not just an upgrade is because moving from an on-premise solution to one that supports a multi-tenant environment or cloud-based application requires a total rewrite of the system itself. The new system, even if it has the same name, is literally and purposefully a different code base. There are a number of consequences of this change.
When you rewrite the code for an entire software package in a new language for a new purpose and new platform, you have to start somewhere close to the beginning. Sure you can move some things early, but you won’t get around it at some point. Many software vendors try to disguise this total rewrite as “just an upgrade” and even go so far as sharing naming conventions. For example, the outgoing Microsoft product is Dynamics AX. The new one is Dynamics 365. Same name, totally new implementation. The same name is to make you think it’s easy.
Microsoft is also a great example of how far this issue can travel down the implementation network. Because Microsoft relies almost exclusively on a network of SIs and VARs, the issue becomes compounded. Microsoft rewrites their software first and determines how it should be implemented. Then they have to teach their SIs how to implement it, which delays the product’s entry into the market.
VARs are even further down the path. For those of you who have a Dynamics AX platform that has intellectual property built into it by a VAR, those systems take the longest to catch up. If your Microsoft partner talks to you about their “proprietary accelerators” you probably have a VAR. They have to get the new code, learn it, learn how to implement it, and then write their own new code in a new language for the new system.
That is why it’s not just an upgrade. It takes many years to rewrite a new software system and design an implementation program for it. It takes just as long to learn that implementation program, and just as long still to rewrite IP for it. All of which is happening in the market right now. SIs and VARs shortcut this by learning and rewriting on client’s time and money. I have a client today who is finding code they wrote for their Dynamics instance in their VARs environment and they are being charged for it!
Vendors Love That You are Dependent on a Single Program – SAP
One of the most challenging catch-22s in software is the value and risk of a single program’s dominance. Nowhere in software is this more clear than with SAP. It’s no secret in the industry that SAP’s flagship ERP is a complete solution that runs all facets of just about any business. This is why so many SAP clients buy so much from SAP. They get it all in one solution. Pretty cool, huh?
No tricky integrations. No multiplicity of vendor relationships. Just one system. You can’t blame anyone for wanting that. So you buy SAP ECC6, and you buy all of it. As much as you can. You transform your entire business, processes, job descriptions, and everything else to revolve around this one, comprehensive system. You create an IT team that knows SAP and not much else because they don’t need to know much else. This becomes a culture for your organization – a culture of efficiency driven by SAP.
Then it happens. To many people, it happened years ago. To others, it’s still a piano hanging by a thread above their head. SAP declares “support for ECC6 will end 2027.” What does this mean? It means in 2027 SAP will begin charging to support legacy ECC6 platforms. Extended support will be 2030 which means SAP will no longer support ECC6 at all. How can they do this? Your organization lives, breathes, eats, and sleeps SAP. So do many others. That’s exactly how – your options are SAP S/4HANA or someone else.
For most SAP organizations “someone else” isn’t really an option. I work with a business that is SAP, inside and out. It’s not just a system, it’s a culture for them. For organizations like this, the new implementation with SAP is the easy way out because they’ve made the alternative so hard. SAP bet big on this, and Oracle thought they’d be raking in disgruntled former-SAP clients. SAP won that bet because of the cultural indoctrination. Better get moving.
ERPs Take a Long Time to Mature – Oracle
Perhaps the biggest issue with the migration to a new ERP without understanding that it’s not just an upgrade is that the new system is always less mature than the old one. How long have you been on your current ERP? Many are 15 years to 20 years old, or even more. Oracle deployed its Enterprise Business Suite platform in 2001 for the first time, which means if you count R&D it has had easily over 25 years to mature. Over that time it became arguably the most comprehensive software package on the planet. EBS does everything.
Early iterations EBS’s successor, Oracle ERP Cloud, debuted in 2011 as Fusion and arguably weren’t ready. Many early adopters of Oracle Fusion jokingly called it ConFusion. I’m not sure that this moniker has been entirely shaken even to this day, but that’s not the point. The point is that it the program has had far fewer years to grow, which means fewer opportunities for development, improvement, and adding functionality. Think of it like moving into a house – a new house is usually empty and you have to fill it up. Then you make changes, make it your own to make it fit your needs over time.
Today, Oracle ERP Cloud still cannot match the functionality in EBS. I’ve seen it multiple times with clients who decided the gaps in functionality were so significant that they decided to abandon their ERP Cloud initiatives all together. One of these cases was a net-new ERP deployment that went to Oracle ERP Cloud and failed because of functionality that was supposed to be there but wasn’t fully developed. The other was a successful EBS implementation that was intended to migrate to ERP Cloud, which was one of the major buying factors for the client in deciding to go with Oracle in the first place. However, functionality gaps between EBS and ERP Cloud caused them to revert to EBS and stick with it long term. In both cases the ERP Cloud program was ended because the product didn’t have the functionality required.
The Strategy Confluence in Moving to the Cloud
One of the biggest hallmarks of modern technology is the endless possibilities made real in the cloud. You hear it everywhere, the cloud for your pictures, the cloud for your media consumption, the cloud for your business. Access whatever you want, from anywhere, at any time. Run your business from anywhere, any time. In today’s world, the cloud is as necessary to running a business as electricity.
What this means for you is that taking advantage of the technology available in cloud software, the internet of things, industry 4.0, AI – you name it – depends on your ability to get onto the cloud. For this reason, you and many others are creating entire strategies that are dependent on cloud technology. It’s not apocalyptic to say the future of business depends on your ability to get into the cloud and do it well.
The problem most organizations have is that they are setting technology objectives that depend on modernization through the cloud and the actual strategy for executing them is left to happenstance. We’re going to use AI. We’re going to implement IoT. We’re going to integrate with SaaS platforms to run our business. These are all great things but you need to ask, “how are we going to accomplish these objectives?”
AI is my favorite example. Every single executive out there has thought about using AI to propel their business into the future. Only a small handful have taken the next step to identify how, where, and what they expect to achieve. Most providers of AI services are out there with the message that AI is easy and it’ll take care of itself. It’s easy to fall into that trap. Many of them don’t even know how they’re going to use their own AI, they’re in such a hurry to establish a win that they’ll say anything. If you’re calling your technology objectives technology strategies you create a ton of risk in getting unintended results, and many will not be good ones.
This is when it comes to AI, just like everything else and every other groundbreaking technology change, it’s not just an upgrade. AI needs data, which needs to be clean and relevant. It needs challenges to confront and users that understand how to draw benefits from it. One of my favorite projects right now is an R&D project where our client is working to understand what AI can do for them and if it can actually do what they think it will and want it to do. This client wants to know what they can do with what they have, what they will need to create to do more, and whether or not it’s even possible. That’s smart. That’s my kind of AI strategy – define the value by having a project to define the value.
The Change You Seek in Modernization – People and Process Confluences
Outside of the occasional existential threat to the business, the reason organizations seek to modernize boils down to two core principles – gains in efficiency and gains in effectiveness. If you’re the type that considers the adage that if you’re not growing you’re dying, or today’s innovate or die mantra, these principles are existential in nature anyways. Looking into these objectives, I always like to think about how those gains are achieved through technology. Processes are improved by the people who deploy and use technology to achieve greater efficiency and effectiveness.
The technology confluence cannot exist without corresponding confluences with people and process. Whether it’s ERP, AI, or some other form of technology, it is created, deployed, and used by people one way or another. The outcomes are designed to enable people to make better decisions more quickly. The challenge comes in the assumption that the outcomes will be self-evident and ease of use will come out of the box, which is a core falsehood of any “it’s just an upgrade” myth.
Any upgrade, no matter how small, requires a change in behavior. For the user who spends an extra click, an extra moment, or an extra day figuring out what changed it wasn’t an upgrade at all unless they were ready for it and knew what benefits to expect. Organizational intelligence is dependent on knowing how to help your people use new tools regardless of the magnitude of the change or the perceived impact.
Once users are adept at knowing how to use new tools, their experience will be improved and their behavior will change to create benefits in efficiency and effectiveness. This comes with inherent process improvements which need to be part of the anticipated and defined improvements benefits. The key to the confluence between process and technology is to enable, automate, or eliminate processes. From this point of view, anything that is just an upgrade isn’t really valuable – if it doesn’t create lasting change then what’s the point? Lasting change in technology comes from the confluence between people and process.
What You Can Do on Your Own Terms
The moniker that “it’s just an upgrade” is a myth pushed by software vendors, system integrators, and value added resellers. It’s designed to make you think buying into the new technology they are offering is easy, low risk, and inexpensive. For the types of technology that are on the market today, whether it’s ERP, MES, CRM, AI, or anything else, the truth is much more complicated. But you can’t exactly do nothing. At some point improving your technology environment is necessary for growth.
The first thing you should do is step back and look at the landscape in front of you and get the lay of the land. What do you actually need – does your Microsoft Dynamics AX platform still work just fine? Could you get more out of your SAP ECC6 environment through the wide variety of third party support organizations that are bound to pop up in the coming years? Do you actually know what functionality you have in your Oracle EBS system that is critical to your business’s fortitude? Dictate your own urgency. If the answer to these questions leads you to believe you need new systems, then that’s more meaningful to your journey in the program that is certainly not just an upgrade.
From there, define the benefits you expect to gain from the technology confluence you seek to achieve and create a strategy for getting there. Don’t confuse objectives for strategies – if you want to use AI that’s a great objective. However, without actionable direction the objective itself will yield limited benefits and could cause more harm than good. Define what you are looking to gain from technology strategically, then define the technology that fits the expectation. You might be surprised to find that what you think you’re going to get from AI is actually achievable in other ways, for example in the Business Intelligence tool you already have. Or you may find that your expectations are well aligned with the tool you seek, but that you need a ton more work to be ready for it. Better to find that out now than after you spend the money and are six months in and halfway to nothing.
Once you’ve determined what your goals and expectations from the technology confluence are and how you are going to tackle them in the strategy confluence, reverse engineer the change itself to fully incorporate the people and process confluences. Work backwards from having the end in mind through the steps needed to achieve the results you are working for. Identify the processes you will improve and how your people will benefit from those improvements. From there, work your way back forward using your strategy to define the path for executing those changes, enable your people to actually affect them and deploy them effectively, and then deploy your new technology to pull it all together. Sounds easy, right? It is just an upgrade, after all.
If you’re looking for help with technology and are considering a change that isn’t just an upgrade, please reach out to us. We live and breath this stuff, and would be excited to listen, share an idea or two, or lend a helping hand.
