IBM Systems Magazine, Power Systems - September 2017 - 40
include Db2. By doing that, these
clients can keep their current
application stack running on
IBM i while migrating their SAP
systems to SAP HANA on a Linux
LPAR, he notes.
Similarly, AIX* clients can
keep their application tier, but
may need to run the SAP HANA
database within a Linux partition.
This move allows them to keep
the high uptime and reliability
inherent with AIX.
Clients running an SAP
NetWeaver stack on IBM i or
AIX go through fewer steps in
migrating to SAP HANA. For the
SAP NetWeaver stack, clients
can host the application tier
on a system different from the
system they host the database.
"If clients are running NetWeaver
on Oracle or IBM Db2 today and
want to migrate their database to
SAP HANA, it would be a simple
database move," says Short.
Clients must be running one of
"If clients want to keep the
competitive edge they
receive from running SAP
software, they should start to
plan their migration to SAP
HANA now, with
SAP S/4HANA and
SAP BW/4HANA in mind."
-Mark Short, lead migration consultant,
IBM Systems Lab Services Migration Factory
the more recent versions of SAP
NetWeaver to use it with
Pick Your OS
Unlike other SAP applications
that run on IBM i and AIX, the
SAP HANA database currently
runs only on Linux. That
requirement doesn't mean
clients need to leave their OS of
choice to leverage the integrated
database capabilities of SAP
HANA, however. Because the
IBM Power Systems platform can
handle multiple OS environments
with ease, clients have the option
of easily adding Linux with a
dynamic LPAR, while keeping
their applications systems
running on AIX or IBM i.
"If clients want to keep the
competitive edge they receive
from running SAP software,
they should start to plan their
migration to SAP HANA now,
with SAP S/4HANA and SAP
SAP HANA Migration Steps for Power Clients
Here are 11 basic steps for a migration of a typical SAP landscape as conducted by the IBM Migration Factory.
The steps include a production instance, a quality assurance (QA) or test instance and a development instance:
Verify the hardware is installed and all of the virtual servers are provisioned with OS, network and storage
before the start of the project. Hold project kick-off meeting with the customer and the migration team.
2. Install and set up the SAP migration tools for the production instance. Perform the first mock database
migration of the production instance.
3. New application tier servers are installed as part of the database migration for all of the instances.
4. Following first mock migration of the production system, client tests system.
5. While the client tests the target production system, the migration team performs the first mock migration of
the development instance.
6. Perform the second mock migration of the production instance.
7. Client tests target production system and system level functions such as high availability, disaster recovery
8. IBM assists the client in cloning a new QA/test system on the target.
9. Once all tests are done, the source production instance is frozen prior to the go-live weekend.
10. When the go-live starts, the client stops the application on the source and turns over the production database to the IBM team for migration.
11. After the database has been migrated and validated, the client tests the database. Then the client decides
if the business will switch to the new servers or if further work is needed.
40 // SEPTEMBER 2017 ibmsystemsmag.com