Do you have a case open? The requirement for the same size or higher NVRAM is definitely met source to target (same 2GB on each system). This definitely looks like a conformance bug... do you also meet the requirement that both source and target are both HA pairs?
Are you trying Online or Offline migration. I believe its offline since you mentioned you did it successfully using the filer CLI, as you can't do Online migration using filer CLI.
FAS3270 seems like a new platform and DFM4.0.2 seems not to recognize it. If you have opened a case then this can be tracked by a burt. If you are blocked in your progress, then I think there is an option that you can set in your 4.0.2 server which can bypass this test and allow you to proceed. I'm not sure if I can disclose the option in public community here since its hidden and not for common use.
I would be careful using testpoint overrides... for simulator and training they work well, but for production I would be concerned that other tests that guarantee a successful failover in 120 seconds are met.
vfiler migrate often finishes quickly (manually and within the same time frame, but just no guarantee of the cutover time and no failback if it takes a long time... 2.5 hours in your case..).. that is a long amount of time especially if the mirrors are up to date. Do you have millions of small files? It sounds like a snapmirror issue to also troubleshoot in addition to the 3270 bug with data motion.
I'm not against the model number since it gives info on the NVRAM and requirements for that system...but it should be included like you said with 6+ months and also there should be release notes that state when a model is not supported or is supported. vFiler Data Motion feature is a great feature but has many limits including a lock in 7.3.3/.4/.5 to even use it. Many customers wanted to upgrade to 8 so we are limited in the 7.3.3+ code line only... and the recent 4.0.1 and 4.0.2 releases allowed 7.3.4 and 7.3.5 to work. 8.1 will add support into the code line and will be the next version of this feature.
• Data Motion is a guaranteed 120 second vfiler migrate for no downtime movement of vFiler units between physical controllers using NFS and iSCSI (CIFS needs to reconnect similar to a cluster failover). Applications run uninterrupted or “always-on” during the migration.
• Use cases are scheduled maintenance, outages, technology refresh, load balancing, adjusting storage tiers, etc.
Data Motion Rules and Requirements
• Destination System NVRAM must be the same size or larger (no rollback if larger) than source
• No migration between heads in an HA pair
• No migration from Faster RPM to Slower RPM disks but can go from Slower to Faster RPM (but no rollback if not the same speed)
• No single controllers on source or destination (must be on a HA pair)
• vFiler source must own all volumes (not just the qtree)
• Data ONTAP 7.3.3 or greater 7.3.x release
• Operations Manager 4.0+
o Provisioning Manager 4.0+
• Does not work on vfiler0
• Host Protocols Supported
• Host Protocols NOT Supported
o FCP, FCoE (only allowed in vFiler0)
o CIFS (it works, but users have to reconnect similar to a cluster failover)
• ONTAP licenses
o SnapMirror, SnapMirror_sync (free with snapmirror)
ONTAP 184.108.40.206 and 7.3 support SMB2. Unfortunately the durable file handle is not at the application level so it isn't really durable when a port moves between controllers with a cluster failover or data motion/vfiler migrate. Maybe there will be an SMB 2.1 that works more like nfs (one can dream )... not a NetApp issue with the durable file handle not being durable.