How to migrate data from 7mode to cluster mode ?

We can use LUN migration tool 7mtt or through Snapmirror also data can be migrate from 7 Mode to Cluster Mode

For NetApp, Data ONTAP 7-Mode is on the outs, and Clustered Data ONTAP (cDOT) is the wave of the future. If you have older NetApp systems in your shop running on 7-Mode, chances are you may already be thinking about transitioning to a newer filer that uses cDOT.

For bigger enterprise NetApp environments, there’s clear upsides to Cluster Mode with features such as seamless controller failover, movable aggregates, and more robust flex volumes. But for small and midsize NetApp shops, the value proposition of moving to Clustered Data ONTAP isn’t so cut and dry.

Depending on your environment, there are cases where it actually makes much more sense to hang onto your older 7-Mode system.

We can use LUN migration tool for migrating data from 7 Mode to Cluster Mode

SAN Data Migration

Currently, NetApp offers the DTA2800 as the best LUN migration tool for moving this data from 7-Mode to clustered Data ONTAP while minimizing downtime. It supports both online and offline FC and iSCSI SAN data migrations. The DTA2800 can be used not only for 7-Mode to clustered Data ONTAP migration, but also for migrating from third-party storage as well.

The DTA2800 uses a 1U chassis with two hot-swappable blades. Each blade is capable of transferring about 4TB/hr. Check out the available DTA2800 documentation for more details.

Qtrees, SnapMirror, and SnapVault

As we said in the introduction, there are three features in 7-Mode that generate a lot of questions when it comes to the transition to clustered Data ONTAP: qtrees, SnapMirror, and SnapVault. As you can tell from the preceding discussion, 7MTT takes care of volume SnapMirror quite nicely. The other two are discussed below.

Qtrees. Qtrees in clustered Data ONTAP are meant for quota management and to support subvolume NFSv3 export policies. 7MTT version 1.2 automates the process of migrating qtrees and associated export policies to clustered Data ONTAP 8.2.1. (As you may have heard, earlier versions of clustered Data ONTAP did not support qtree exports, but that support has now been added.)

Data ONTAP 7-Mode also provides qtree-level SnapMirror, but this capability is not part of clustered Data ONTAP. If you currently replicate qtrees in 7-Mode, qtrees that don’t have the same replication schedule will need to be broken out into different volumes, either individually or with other qtrees that share the same replication schedule.

The clustered Data ONTAP feature set includes:

• Nondisruptive volume movement
• QoS that operates at the storage virtual machine, volume, and file level

If you want to take advantage of these features, you may want to evaluate your current qtree configuration and determine if it needs to be reorganized.

In relation to qtrees, you should also note that exports work differently in clustered Data ONTAP; they are policy based and greatly simplified. A source of confusion has been the “number” of exports supported with clustered Data ONTAP. The number you often hear cited is the number of export policies we support, not the number of individual export rules, and you can have many, many individual rules per policy, so the limit is actually much higher. For VMware users, there’s a tech report on vSphere best practices, TR-4068, that describes how to use export policies and rules most effectively.

SnapVault. SnapVault exists in clustered Data ONTAP; however, SnapVault in 7-Mode is qtree based, whereas SnapVault in clustered Data ONTAP is volume based and is able to retain storage efficiency savings during transfers. From the perspective of the primary volume, there’s no change. From the perspective of the secondary—vault—volume you end up creating a new clustered Data ONTAP vault that requires a baseline (because it is a net-new relationship). This raises the question of what to do with all the data stored in the 7-Mode vault.

• If you keep data for less than three months we recommend that you keep the 7-Mode system in place for three months until you build up the necessary retention cycle in the clustered Data ONTAP vault. If you need to restore from the 7-Mode vault during that time, you simply mount the Snapshot copy from the 7-Mode vault and copy out the data you need to restore.
• If you need to retain your SnapVault data for more than three months (more common), you again start a new vault on the clustered Data ONTAP system, but you also migrate the existing 7-Mode vault to the clustered Data ONTAP system into a separate volume (from the clustered Data ONTAP vault). In that way you can get rid of your 7-Mode equipment and still have access to data in the 7-Mode vault for restore if necessary. Again, you have to mount the Snapshot copies from the migrated 7-Mode vault in order to restore (the clustered Data ONTAP vault operates normally).

Note that the three-month cutoff is a guideline, not a hard rule.

Operate Your New Environment

The Operate phase is where you “operationalize” your new clustered Data ONTAP environment. This includes the following.

• Verify, upgrade, or deploy the management tools necessary to manage the clustered Data ONTAP environment.
• Internal processes have to be adapted to take advantage of changed capabilities and new features of clustered Data ONTAP. For example, you’ll very likely want to take advantage of the ability to nondisruptively move volumes, which warrants a new process to guide administrators as to how to determine where a volume should be moved, when it should be moved, and so on.

Most of these changes are small or incremental, but they shouldn’t be overlooked