Hi Jorge,
let me start with the fact that reshapes the whole question: FlashCopy (and its successor, the Snapshot function) works inside one system only. Your daily flow works today because production and dev/lab volumes live on the same SVC cluster, so the copies are intra-cluster. Once production moves to the FS7600 PBHA pair, there is no supported way to take a FlashCopy on the new boxes with the target sitting on the SVC. So the function cannot be recreated as-is across the two worlds, it has to be redesigned. Two realistic patterns:
OPTION A, the one I would actually build: keep the copies on the FS7600s and serve them to dev/lab from there. You schedule snapshots of the production volume groups on the new systems (snapshot policies, Safeguarded if you want immutability), create thin clones from the snapshots, and map the clones straight to the lab and development hosts. The dev/lab servers keep their primary storage on the SVC, they just get an extra zoning to the FS7600s for the refreshed copies. Cost: clone capacity and some ports on the production arrays, plus sizing the cache/IOPS headroom so lab work does not disturb production. One thing to verify on your exact target 9.1.x level is the supported combinations of snapshots with policy-based HA volume groups: the compatibility page below explicitly points to the Replication topic of each release for the supported configurations, so check it for the level the 7600s will ship with.
OPTION B, the one that looks natural on paper: asynchronous policy-based replication from the FS7600 PBHA pair to the SVC, and then clone the replica on the SVC for dev/lab. Architecturally this is the "HA plus DR to a third system" combination, and IBM supports it from 8.7.1 onwards. But there are two hard gates on your specific hardware. First, the partnership levels: per the official compatibility cross reference (updated March 2026), the 8.5.2 to 8.6.3 stream only partners with itself and with 8.7.0, not with 8.7.1 onwards and not with any 9.1.x, 9.1.2 included:
https://www.ibm.com/support/pages/ibm-storage-virtualize-policy-based-replication-and-high-availability-compatibility-cross-reference
So this whole option hinges on a single question: what is the highest level your SV1 nodes can run? If I remember correctly they top out in the 8.6 stream, and in that case the matrix closes the door, full stop. If they can reach 8.7.0 (verify it on the concurrent compatibility page: https://www.ibm.com/support/pages/concurrent-compatibility-and-code-cross-reference-ibm-storage-virtualize), a partnership with the 9.1.x on the 7600s would be allowed by the matrix, but you would still be building on hardware with an expiry date. And there is no fallback via classic Metro or Global Mirror, because IBM has officially declared 8.7.0 the last release with Remote Copy, and the new platforms only speak policy-based replication:
https://www.ibm.com/support/pages/node/7166967
Second gate: the 2145-SV1 reaches End of Support on December 31, 2026:
https://www.ibm.com/support/pages/node/7092523
Building the new production copy workflow on a platform that exits support in a few months is a foundation I would not pour. My read: with SV1 nodes, option B is at best a short-lived bridge and more likely a dead end, and it only becomes truly viable if the SVC nodes get refreshed, at which point the whole picture gets rediscussed anyway.
And one honest note that goes beyond your question: that same IBM page states that Remote Copy includes HyperSwap, so the topology your dev and lab volumes stay on is itself on the sunset path, on hardware that goes EOS at the end of this year. If I were driving this project, I would use the production migration as the trigger to plan the exit for the whole SVC estate, not just production.
If you share the exact code level your SVCs run today, the 9.1.x level the 7600s will ship with, whether the dev and lab hosts can be zoned to the new arrays, and what the copies need to be (writable clones, how many, what retention), I am happy to go deeper on the design.
Regards
Roberto
------------------------------
Roberto Renna
------------------------------