Earlier this year, our team saw a big spike in activity as we migrated SAP systems to new hardware for Windows 2003 support ending. We perform SAP hardware migrations regularly for a broad range of customers as part of our remit to supply technical support for their SAP systems.
This blog consists of my thoughts on the best approach to a hardware migration based on my experience of planning and delivering them for our customers.
Why do a hardware migration?
There are three common reasons that drive an SAP hardware migration:
- Hardware has reached end-of-life
- The Operating System has reached the end of vendor maintenance
- Virtualisation or a move to the cloud
Combining Advantages
Our approach to hardware migrations is based on gaining as many advantages as possible with a single project. A single migration, with a single set of downtime, business impact, testing, and cost, can deliver multiple benefits.
Regardless of the main driver for a migration, we generally try to achieve all of the following advantages:
- Choose the best hardware option
- For physical hardware, move to new hardware to maximise warranty time and reduce risk without a further migration.
- For virtual hardware or the cloud, move to the newest platform that is available within the wider strategy of the IT department, without further remediation to bring SAP in line later.
- Choose the best technology stack for the evolving needs of the business
- The latest version of the platform that was best for your organisation during a SAP implementation in 1997 may not be the best fit now.
- SAP now recommend a migration to SAP HANA at the time of any major SAP project, as this can deliver significant speed increases today as well as preparing your system for future innovation from SAP. Non-HANA databases are currently supported by SAP until 2025.
- Choose the latest versions now to avoid work later
- Move to the latest supported release of the database software and operating system to maximise the length of vendor maintenance.
- Move to the latest supported backwards-compatible SAP kernel to reduce the need for future downtime and cost when it gets updated.
- Implement additional advantages available from the newer technology stack, such as database compression, which can often be done during a migration with less impact than doing it in-place after.
- Be aware of the future
- Move to a technology stack that supports any planned SAP projects, for example an enhancement package or upgrade. Being aware of future plans at the time of a migration can reduce the costs later, and make an upgrade business case easier if you are already prepared.
- Align the SAP landscape with the wider strategy of the IT department, possibly including a move to the cloud, a move to virtualisation, a change of operating system or a change of database, all to simplify and streamline the wider operations of IT.
How to Create the Optimal Migration Project
When you start planning the ideal migration project, it’s important to remember the headline driver for the migration. Whether the hardware is beginning to creak or the operating system is out of support, whatever is driving the need to migrate is the main point for your business case.
The next step is to start looking through the above list to find as many secondary advantages as possible, checking what extra effort is required to realise each one against the benefit it delivers before adding to the business case.
Some advantages are quite easy to spot, for example finding the latest database and operating system that your SAP system supports from the Product Availability Matrix (PAM). Consider the minor risk of using the bleeding edge against the advantages of knowing you don’t need to touch it again for the length of vendor maintenance on those products.
Some potential advantages are more difficult to see straight away. How do you know if your proposed migration prepares you for future SAP projects? Indeed how do you even know what future SAP projects you might do? To bring that knowledge into the process you need to prepare a roadmap for the landscape.
A roadmap exercise will identify all business requirements for SAP functionality, and propose projects with indicative costs for budgeting to achieve those requirements. The roadmap is the opportunity to identify the required projects and put them in the most efficient and technically valid order.
In the majority of roadmap documents that I have seen for our customers, there is an identified requirement to get a supported operating system or better hardware for the proposed projects. If you can bring those requirements into a hardware migration project that you are already planning, you can add plenty of secondary advantages from reducing effort later.
Business Impact
Taking time to create the optimal migration project reduces business impact as you can do a single migration and avoid doing it again for many years, but you will still have some impact on your business.
Downtime is required as you physically move the systems, so we tune this process during development or sandbox migrations to minimise and predict the time taken. As a migration doesn’t change any business logic, only minimal testing is required, but it should focus on interfaces as connectivity issues are the most common post-migration problem in my experience.
Actually Moving your SAP Systems
When the optimal migration project is specified and the business case is approved, you start planning how you are actually going to do it in technical detail. This is where you need to be aware that the only supported method to move a SAP system is to follow a SAP system copy process.
You cannot move a SAP system with automated virtualisation tools (P2V), cloning of servers or ghost-style copies of entire systems. Some SAN-level disk mirroring or backup software can be supported in certain homogeneous cases to perform the actual movement of data, but you must still follow a SAP system copy procedure to move the application. In-place upgrades of operating systems are supported only with heavy restrictions.
Using any process that isn’t supported by SAP can invalidate your software maintenance and leave your organisation at major risk of having a fault with software that’s used in a critical business process.
A desire to use an unsupported migration process is the most common problem that I have seen with SAP hardware migration projects, but it remains popular as employing specialists to run SAP’s tools seems like a costly approach. However, the SAP system copy process provides the flexibility to use a different database and operating system making it fundamental to gaining most of the possible secondary advantages.
Post Migration
A well-planned migration project delivered by experienced people is straightforward to deliver on time and budget as no business processes are changed and minimal involvement from outside IT is required. After a recent complex migration I wasn’t sure whether to be pleased with feedback that it had gone “unbelievably” well at first but I chose to take it in good faith.
You can promote the success of the project amongst your user base whilst informing them of how long it will be before it’s required again as a result of the effective planning that went into it. Then there’s one final advantage to glean from the hardware migration; you can use any preparation you’ve done for future projects in the next business case, to start implementing new functionality for your business.
For more information about the topics covered in our blog, contact Absoft today via: info@absoft.co.uk or T: +44 1224 707088 to speak with our SAP consultants.
