Yes, DECnet can work here.
And yes, all recent versions of ftp can be and variously are used to transfer multi-gigabyte files. (Some of the oldest of the ftp software that's been around might toss a snit, though.) HP uses ftp to download multi-gigabyte OpenVMS kits to customers quite regularly, after all.
100 MbE is slow, but this data-transfer operation clearly isn't time-critical.
The biggest issue with transferring larger files tends to be flaky network configurations, or flaky hardware.
One of the fastest ways to the transfer data involves adding a little extra storage hardware, and hauling stuff across on disk bricks. Depending on the hardware that's added, you also have a backup copy, and some extra storage, and a connection for (for instance) an external SCSI tape device. (But then this data transfer and this migration doesn't look to be time-critical.)
If using a network and ftp, then using current versions of zip and unzip (if you have extra storage to hold the intermediate files) can be used to compress the data for a faster network transfer. zip 3.0 and unzip 6.0 (current, or later) can deal with multi-gigabyte large files. (Older versions of zip and unzip cannot contend with larger files.)
it's also possible to zip a BACKUP saveset and ftp that, as HP does with variois of their software kits and software distributions.
If you do choose to use zip and ftp as part of this approach, then remember to use "-V" - that's a quoted, uppercase V, and the quotes and the uppercase are mandatory in the most common OpenVMS command-parsing environment - to cause zip to save the RMS file attributes.
The "gold standard" approach here is usually clustering. Clustering allows the old and new systems to share all storage, and access all storage. This then allows the current and new environments to operate entirely in parallel, meaning that the transitions and the migrations can be incremental.
And getting the files transferred is the smaller part of the project.
I'd expect that a brute-force transfer of a storage configuration as small as 300 GB should have been completed in a few days time to maybe a week on the outside, with that time involving setting up the DCL procedures, and waiting for the (lack of) speed of that 100 MbE connection, and then contending with whatever errors that Ethernet connection might encounter. If all the computing hardware, storage and network hardware is correctly configured and working properly, then this transfer is probably a couple of days to implement, to transfer the data, and verify the results. This data transfer is (usually) the easy part of a port. Getting the applications and source code ported can sometimes take rather longer than a week.
