01 / BASELINE & DESIGNStart with what is actually there.
Capture the SAN configuration, storage layout, workload dependencies and recovery arrangements at both sites. Survey racks, power, access and connectivity before sizing the replacement.
Compare usable capacity on a consistent basis: units, protection overheads, reserves and growth all matter. Check CPU, hypervisor and application compatibility across old and new hosts. Where SAP HANA is in scope, verify the support requirements for its deployment rather than applying a blanket rule to the whole estate.
Gate: an agreed design, dependency map, acceptance criteria and rollback plan.
02 / PARALLEL BUILDBuild the replacement alongside the live estate.
Provision the new fabrics, arrays and replication paths while the existing environment remains available. Back up configurations and review zoning changes against the current connectivity map; use additive changes where practical.
Validate access, multipathing, replication and monitoring before moving production workloads. Establish and test the backup protection needed for the migration, including responsibility for restores.
Gate: a validated target environment and a recovery path ready for the first workload.
03 / PHASED MIGRATIONLet a pilot set the pace.
Move a representative, lower-risk workload first. Record transfer time, application behaviour and the effect on the shared platform. Use those observations to set batch sizes and change windows.
Use live migration where the platform and workload support it. For other moves, agree the interruption, communications and rollback triggers in advance. Confirm application health and backup coverage after each batch.
Gate: accepted pilot results, followed by a recorded decision for each migration batch.
04 / RECOVERY VALIDATIONTest recovery, not just replication.
A replicated copy is not a substitute for an independent backup. Design separate recovery copies, appropriate failure domains and access controls. Use supported immutability or object-lock settings to protect backups against alteration or deletion during the configured retention period.
Check those settings and their administrative boundaries. Test restores and the agreed disaster-recovery procedure against the agreed recovery time and recovery point objectives. Validate application dependencies as well as data availability.
Gate: recorded restore and recovery results, with gaps resolved or explicitly accepted.
05 / CONTROLLED RETIREMENTRetire the old platform with evidence.
Decommission only after production acceptance, recovery validation and agreement to close the rollback window. Treat historical backup retention and legal holds as separate decisions; replacing an appliance does not remove those obligations.
Choose a supported data-sanitisation method for the media and its configuration. Cryptographic erasure may be suitable where its prerequisites are met. Retain the sanitisation records and update the asset inventory as equipment leaves service.
Gate: an authorised retirement record, retained-data ownership and evidence of sanitisation.
06 / OPERATIONAL HANDOVERLeave a record of what was built.
Update addressing, zoning, port maps, replication, backup policies, licences and support contacts for both sites. Reconcile port maps with the installed configuration, including switch neighbour information where available.
Agree operational ownership, monitoring, restore procedures and secure access handover. Record outstanding actions with an owner and a due date.
Gate: accepted as-built documentation and an operations team ready to manage the environment.
Explain the choice before making it.
A dedicated backup server and a virtual appliance carry different cost, dependency and recovery implications. Present the options and record the decision. Likewise, distinguish a power estimate based on vendor ratings from measured consumption; they answer different questions.