Sounds like what you are describing should work.
I would try creating the new table, open a second window so you have both tables open in their own windows, and be sure all records are in the found set of the source table screen. Then try a direct import from the source table to the new table of just those two fields. (That worked for me when using v12, and you could always resort to the export to an intermediary file and then import if the direct import between open windows fails.)
If you do hit a snag due to the storage method, you could change the storage method of the source file via the Manage Container data dialog, then, when the containers have been internalized, take the file down and open it locally to run the import/export routines. Local files might speed things up, but that's hard to know without any clue how much container data is involved.
I agree with Stephen: work from the new file to import the records. FM will then handle all the external data transfer for you acording to the settings you give i the new file.
It worked for me going from table to table although I worked through the same window. I went to a layout for the table I was importing from and did a find to get a subset of the records (I'm taking it in small bites since there's no real hurry except for the very recent records). Then I switched back to a layout for the table I was importing to and started the import going out to Remote file, selecting the file I already had open and then aligning the tables correctly for field matching during the import. It is slow but has been pretty simple and some how feels easier than going the intermediary file route.
Yeah, moving container data is slow, and the more you have, the slower it goes.
Glad to hear it's working out for you to use the most direct method.