IBM TotalStorage is a historical brand spanning distinct storage systems. For a legacy DS6000 or early DS8000 installation, the first migration deliverable is an accurate inventory linking hardware, firmware, hosts, volumes and application dependencies. That inventory allows the responsible storage and application teams to establish a supported migration path.
Locate the documentation for the exact generation
The DS6000 and DS8000 names appeared in the same era but identify different systems. IBM’s DS6000 Series: Architecture and Implementation documents the DS6000 architecture and planning context. Later DS8000 publications cover later generations. Similar branding does not make their procedures, code levels or interoperability requirements interchangeable.
Record machine type and model, serial number, installed controller or management code, expansion configuration and licensed functions. Match each document to that inventory and retain the document edition. The IBM DS8000 documentation index helps locate generation-specific material; a current guide does not establish support for an older array.
On narrow screens, focus the table and use the arrow keys or swipe to see every column.
| Layer | Evidence to capture | Decision it supports |
|---|---|---|
| Array | Machine type/model, code level, capacity and installed options | Identify applicable documentation and supported methods. |
| Host path | Host OS, HBA, driver, firmware, fabric and multipathing | Establish an interoperable destination connection. |
| Volume | Stable identifiers, size, mappings and application owner | Prevent a capacity-only match from becoming an identity mistake. |
| Dependencies | Copy pairs, consistency groups, schedules and backup jobs | Coordinate application-consistent movement and recovery. |
| Operations | Support responsibility, outage window and acceptance owner | Decide who can authorize and validate the change. |
Map application data rather than counting disks
Build a source-to-destination volume map using identifiers that remain meaningful outside one management screen. Include host presentation, file systems or database use, application owner and protection relationships. Resolve aliases and stale mappings before the change window. A volume that appears unused to one host may serve another system or a recovery workflow.
Record which volumes must represent the same application point in time. The storage team and application team should agree on how writes are controlled, how consistency is established and how the application is restarted. A completed array copy alone does not establish application recoverability.
Choose a method only after compatibility is established
IBM’s DS8870 Data Migration Techniques illustrates the generation-specific nature of migration planning: it addresses particular older DS8000-to-DS8870 scenarios and discusses storage and host approaches. Use such publications to identify questions and applicable methods, then verify the exact source, destination and code combination. DS6000 and later targets require their own applicable procedures.
Possible approaches include an application-level move, a host-based copy or a supported storage replication method. Evaluate each against outage tolerance, connectivity, licensing, consistency, recoverability and the ability to reverse the transition. Obtain support evidence for the chosen combination before writing an execution procedure.
Measure transfer rates with representative data and conditions. Include the initial copy, changed data accumulated during the copy, final synchronization and validation. A calculation using nominal link speed leaves out contention, protocol overhead and application behavior. Schedule a rehearsal that exposes these constraints while there is time to adjust.
Make cutover and rollback reviewable
- Document prerequisites and the checks that establish readiness.
- Name the person controlling application writes and the person validating storage identity.
- Define the point at which the destination becomes authoritative.
- Set measurable acceptance criteria: data checks, application transactions, performance and protection jobs.
- Describe rollback before and after destination writes begin; the latter may require reconciling changed data.
- Retain the source and recovery copies until the agreed validation and retention conditions are met.
A rollback plan must specify where authoritative data will reside, how new writes are handled, and who makes the decision. Simply reconnecting the old array after users have written to the destination can discard those changes. Tie the decision to explicit conditions and a time window.
Use the legacy-array migration readiness record to organize the evidence. It is a planning document for review with the responsible teams. Execution commands and decommissioning steps belong in the approved procedure for the identified systems, after a tested recovery path exists.