I have done a number of these platform conversions and I would always recommend using the E1 middleware and R98403 for the job. I agree with others that SQL tools such as DTS can be used but given the chance for problems and the fact that Orace support would not sanction the copy I would never recommend using non-JDE tools for a production migration.
Here my approach which has generally been able to manage 400 GB worth of data in 18 to 24 hours:
The key weakness of R98403 is that the API it uses, JDB_CopyTable via BSFN B9800200, seems to work on a record at a time. To work around this I run many R98403 jobs in parallel each copying a table or group of tables.
I generate a record count listing by table and then use excel to order them by record count. I then take the top 100 tables or so and create R98403 versions with data selection limiting them to 1 table each. I then throw the rest of the conversions into 1 or a few other versions. I have scripted the version creation process but even if you create 100 versions manually it isn't really a big deal. Realistically you will only do this once and I think the more hands-on your approach is the less chance for error.
The R98403 needs to be run on a fat client. I run 3 or 4 copies of the R98403 per fat client/citrix session. I make sure Citrix is configured to allow disconnected sessions.
If you have an extremely large F0911, F42119, etc. You can get extra tricky by creating a database view with the same name in a DIFFERENT schema/datasource and apply a where clause. e.g.:
CREATE VIEW PRODCPY1.F0911 AS SELECT (*) FROM PRODDTA.F0911 WHERE GLDGJ <= 100000
CREATE VIEW PRODCPY2.F0911 AS SELECT (*) FROM PRODDTA.F0911 WHERE GLDGJ > 100000
Then create a datasource for PRODCPY1 and PRODCPY2. Create two versions of the R98403 which select the F0911 one which uses PRODCPY1 as a source and one that uses PRODCPY2 as a source. You can then run these two in parallel. I apply this technique so that I have the maximum number of jobs running and spread out the copy load as much as possible across all jobs. Obviously you need to tune the number of parallel copies to match your db server's capacity.
While this may seem like a lot of work you would need to put in some fair effort to make SQL DTS as parallel and load-balanced as the UBE approach. Plus with the UBE approach you are using standard tools and will be supported if you run into conversion problems.
Hope this helps.
Regards,