IBM DATA MIGRATION SERVICES Brochure page 23

Storage migrations made simple.
Page 23
Highlights
An insurance company needed
help to maintain availability while
migrating a mission-critical claims
processing application.
Global migration to new servers and new storage
An insurance company was running a mission-critical claims processing appli-
cation on Oracle. It was upgrading from legacy servers running Solaris 8 and
VERITAS Filesystem/Solstice Disksuite to new servers running Solaris 9 and
VERITAS Volume Manager. Six TB (allocated 2TB per server) on an older disk
array were being replaced by a new array.
The insurance company faced these key migration challenges:
• Limited downtime — Only four hours downtime per week were permitted
for any application.
• Hardware move constraints — Only one server could be moved at a time
to avoid risk to the application infrastructure.
• Compatibility of new storage with legacy servers — There were insufficient
connections available to directly attach new storage to legacy servers,
and it was risky to install new device drivers on legacy servers.
The migration options that were considered included the following:
• Offline migration — This would have resulted in multiple downtime
instances, each exceeding 12 hours.
• Array-based replication — This option could not be used due to dissimilar
legacy and target storage, and because disk subsystems were incompatible.
• VERITAS Volume Replicator —This option would have required the installation
of VERITAS Volume Manager on source servers.
• Fabric-based appliance replication — This was rejected because of the risk of
reconfiguring the SAN.
• Kashya — This was rejected due to the requirement that mirrors be set up
and created on the host system. Such an arrangement was unacceptable
given the changes involved and the associated disruption.