As the end of support for SAP ECC looms, the option of migrating to SAP…
An SAP upgrade shouldn’t be risky or unpredictable. You should go in knowing exactly what you’re getting, and your partner should deliver it, period. With the 2025 SAP HANA® migration deadline on the way, it’s time to start thinking about what you need from your landscape, and who can provide it. Here’s what you need to know to get your SAP HANA upgrade right.
What to Expect From the SAP Upgrade Process
Upgrading ERP landscapes like SAP has historically been difficult and risky. Every ERP landscape is an intricate, complex, one of a kind system on an extensive hardware infrastructure, supporting a huge range of users with different needs and roles. Business processes have to move through that system from end to end, supporting your business while minimizing security and compliance risks. Change any one piece, and it can have complex ramifications throughout the system, which are hard to fully model. To upgrade the whole thing, you either need a high appetite for risk, or a well-developed methodology.
Fortunately, the SAP industry has had decades to develop that methodology. SAP upgrade best practices govern every aspect of the process, from the overall project management approach to the finest details of database migration and testing. This is supported by exacting SAP certification and training practices.
This has transformed SAP upgrades into a predictable process with excellent ROI. Your SAP upgrade partners can inventory your strategic, business, and IT needs, and create a solution that matches those needs exactly. A detailed IT project management approach will let you know where the project is at, day by day, and waypoint by waypoint. If you get any surprises, it should be finishing ahead of schedule.
Planning and executing an SAP upgrade is still time consuming — timeframes vary, but 12 months isn’t unusual. It also requires time from internal stakeholders. We’ll need a lot of input up front to ensure we understand your needs and have designed a landscape that can meet them, and there will be training later on, to help your employees harness the full power of SAP HANA. But what there won’t be is unpredictability or major disruption. You’ll know exactly what you’re getting, when you are getting it, and what it will do for you before we begin.
SAP Upgrade Tools and Techniques
SAP has provided a series of incremental improvements that combine multiple tasks, eliminate redundant work, and simplify the HANA migration. For example, older SAP ECC versions requires the application of enhancement packs, NetWeaver upgrades, or even Unicode conversion to meet the requirements for HANA. Traditionally, each upgrade would require a multi-month project, with planned downtime, before the HANA migration could begin.
The SAP Database Migration Option (DMO) allows companies to roll these upgrades and a database migration into a single procedure. This SAP upgrade tool saves a lot of time and limits the process to a single downtime event, cutting disruption and risk.
The release of SAP Solution Manager 7.2 has also simplified the upgrade process. Previous versions of Solution Manager were dual stack. SolMan could work with HANA, but had to be running on a different platform, such as SQL Server or Oracle. Version 7.2 has been completely rebuilt around HANA, offering single-stack support that simplifies the SAP HANA upgrade process.
As an Application Lifecycle Management (ALM) program, Solution Manager provides a range of other useful SAP upgrade tools. For example, SAP EarlyWatch provides detailed analysis of system health, allowing you to spot potential performance bottlenecks before they can interfere with the SAP upgrade process. Extensive project planning features are an asset from day one, and dependency modeling helps your team catch technical dependencies early on, so they don’t have to iron them out later on.
SAP Upgrade Use Cases
The term “SAP upgrade” covers a lot of ground. It can refer to fairly basic changes, like installing an enhancement pack without making substantial tweaks to business logic. It can also refer to sweeping, comprehensive changes that rework your whole ERP landscape, allowing you to harness new features like real-time analytics and IoT.
Historically, many companies have defined use cases very conservative, trying to do the minimum as a way to control costs and avoid disruption. They’ll upgrade SAP when the apps they use stop supporting an older version of SAP, for example, or when their landscape can’t cope with increasing traffic. It’s all reactive — they wait until things are about to break or actually breaking, then do what’s needed to fix the problem.
This approach is shortsighted, and outdated. With the rapid progression of technology and the efficiency of the modern SAP upgrade and migration process, organizations need to start seeing their upgrade strategy as a part of business strategy, and create an upgrade approach that supports business goals as well as immediate technical needs.
To do that, you first need to understand what’s available, and how it will help you. The SAP Fiori UX and new S/4HANA modules can increase agility and productivity, and control costs, but their benefits depend on reworking your business processes around a HANA paradigm.
You should also think about security and compliance use cases. Most companies struggle with compliance, and many still use document-centric techniques that make preparing for audits very expensive and time consuming. Upgrading to an SAP GRC software solution can yield quick ROI, and significantly cut risks, such as fraud and embezzlement.
Finally, think about your hosting and support model. An SAP HANA upgrade is the ideal time to move to a managed enterprise cloud services model. This will control costs, replacing unpredictable OpEx with stable, monthly CapEx.
It also provides a more sustainable support model. Companies that run ERP in-house generally are forced to make IT staff wear multiple hats, which means things like SAP Basis support and IT security are treated as side gigs, which poses risks to your landscape — and your business. With a managed services partner, you can take pressure off your internal team, while harnessing the skills of highly trained specialists.
SAP Upgrade Methodology: Functional and Technical Teams
Functional and technical teams have complementary roles. Your functional team works to identify your use case, and design an SAP HANA solution that supports it. Your technical team are the folks who take that design from concept to reality. They size your system, make sure the dependencies are satisfied, setup your networking and data, migrate, test, and refine the system over multiple stages. In other words, the job of the functional team is to come up with a great solution, while the job of the technical team is to deliver a finished product on time, with no nasty surprises.
While some SAP integrators will try to tack on SAP implementation as a “bonus” service, you get what you pay for. Single-source your SAP implementation, and it’s likely your team will cut corners, leading to delays, poor performance, and costly future remediation.
Additionally, single-sourcing your SAP upgrade project generally means lack of support post go-live. Your functional provider is only making money on creating an SAP solution — it’s in their interest to get out of there as soon as the project is done. A technical provider like Symmetry wants your long-term business for hosting, administration, and so on. We want to be there for tuning and running your system, and we want to be thorough, so that that tuning is as painless as possible.
SAP Upgrade Project Plan: Setting Goals
Creating an SAP upgrade project plan is a collaborative effort that requires input from stakeholders at all levels — and we mean all levels. Executives can set priorities, and IT can specify technical requirements, but you also need input from workers and managers across multiple departments. The SAP project management team needs to understand not just the flow of business transactions across the organization, but the individual roles within those transactions.
Getting everyone involved from the beginning allows you to ensure your SAP upgrade project plan supports strategic goals as well as technical ones. It’s how you make sure performance increases translate to productivity increases, and turn better analytics functionality into better insights.
The right provider is crucial to this process. They need to be able to listen to everybody, come up with a coherent solution, and translate that solution into very specific goals on multiple levels, including:
- Functional goals: What capabilities should your SAP landscape have? How should roles and business logic be changed to harness those capabilities? How can UX be improved to increase user productivity?
- Technical goals: What are the sizing requirements of the SAP upgrade project? What are the requirements for networking, configuration, DR, and so on?
- Project goals: What’s the timeline for this project? What are the waypoints, and what needs to be done at each waypoint? Should this be a multi-stage SAP upgrade? If so, what’s the most strategic way to divide it up?
- Strategic goals: How should this upgrade fit into an ongoing business strategy? What are your medium and long-term goals? How will you revisit those goals to plan or adjust future stages of your upgrade?
- Success metrics: What are the KPIs for your SAP HANA upgrade? How does the system need to be engineered to meet those KPIs?
SAP Upgrade Phases: Technical Project Implementation
SAP upgrade methodology is a bit like an artist painting a landscape. First, the artist blocks out the major shapes with pencil, making sure they’re all positioned correctly in relation to each other to create effective composition. Then, they draw in the main landforms — mountains, lakes, patches of forest, and so on. When they’re happy with that, they go back for another pass, and another, until every detail is perfect. Big issues are tackled early in the project, so that no mistakes sneak through to later phases.
SAP Technical Project Implementation uses a recursive approach for pretty much the same reason: to make sure by the time they’re ready to go live, everything has been tested and tweaked to perfection. This starts with the onsite initiation phase, where we reviews the project with stakeholders. We ask questions and make sure they haven’t forgotten details, such as connecting the system to tax systems, banking partners, and other external parties.
Next, we perform data center and network setup. We size the system, and build a hosting environment that will meet the demands of the landscape.
Later on, there are multiple phases of testing. We iron out any major issues in the Sandbox Migration stage, and learn what needs to change. In the next stage, Dev Migration, we get more detailed, connecting the system to third parties, and making needed adjustments. By the time we’re at Production migration — the final stage — we know what has to happen at every step, how long it will take, and precisely when go-live will occur.
SAP Upgrade: Measuring Success
Much of the success of your project just goes back to your goal-setting. If your system came in on time and does what it’s supposed to do, you’ve had a successful SAP upgrade. However, it’s also important to measure success on an ongoing basis. You need to frequently revisit performance, and conduct performance tuning or resizing to ensure your SAP landscape continues to meet KPIs.
You also need a method and a team to connect stakeholders and plan future upgrades around your company’s changing needs. They need to be able to work with you to ensure your business processes and landscape evolve to harness new technologies and meet new needs.