It’s a typical scenario: a company has implemented some enterprise software, and a newer release is now available. The new features and/or improved performance convinced the decision-makers that it makes good business sense, and the IT team is asked to implement the new software.
The IT team will have to make an important decision: Upgrading or Migrating
Many factors will influence that decision.
- The scope: what is involved in each option? How many users are affected? How long does it take?
- The risk involved: what if something does not go the way it was planned? What would be the impact of such incident? Would it be a minor inconvenience or a disaster?
- The cost: Is there money for new hardware?
- The timeline: which option will be faster to implement?
A careful analysis of those factors is critical.
Let’s consider the case of SAP Business Planning and Consolidation (BPC). Fictitious Company XYZ is currently using BPC 7.5, version for SAP NetWeaver, and has decided to implement BPC 10, version for SAP NetWeaver powered by SAP HANA.
Its current BPC 7.5 system is running on NetWeaver 7.01 and was installed in 2010.
There are several possible strategies that need to be considered:
· In-Place upgrade
· System Copy of the source system, and then in-place upgrade on the copy
· Fresh installation of a BPC 10 on HANA system, and migration of the BPC content from the BPC 7.5 system
Upgrading, whether in-place or on a copy, means upgrading NetWeaver to 7.30, installing the BPC 10 ABAP component (it replaces the 7.5 component), at which point we have BPC 10 on SAP NetWeaver. Next step is migrating the database to SAP HANA, and then adding the HANABPC accelerator.
That’s a lot of steps, some of them quite complex. That’s disruptive too in the case of the in-place upgrade, as it “breaks” the BPC 7.5 system before the BPC 10 system is ready. And if something goes wrong, well, there’s a risk of ending up with neither system for a while…
The other option is to procure an entirely new system, starting with new hardware. Once procured, it can be set up with NetWeaver on HANA. Then BPC and its accelerator for HANA can be installed, and the system can be validated. All this without even touching the 7.5 system.
The application sets (environments in BPC 10) can be brought over using transaction code UJBR. The transaction data can be brought over in various way, depending on the volume (UJBR, Data Manager, Open hub).
In most cases the migration to a new system makes more sense, for several reasons: limited disruption, limited risk, and the benefit of using new hardware.
An in-place upgrade might make sense on some implementations where there are a lot of customizations dome at the ABAP level, and migrating those customizations to a new system might be more complex than the in-place upgrade to BPC 10 on HANA.
A system copy followed by an upgrade is an interesting compromise, as it avoids the disruption and risk of the in-place upgrade, while keeping its benefits, with the exception of the savings on hardware. However, it’s at the price of an additional step.
It’s also important to keep in mind the life-cycle of the hardware. While being able to continue using the same server, one must remember that in the example above, the BPC 7.5 system was initially provisioned in 2010, so the hardware is almost three years old.
There is no one-size-fits-all answer the dilemma of upgrade versus migration – each case is unique, with its specific requirements and constraints. But it is important to consider all the variables that will have an impact on the project.
