Если взять сферическую базу, то...
На скорость записи, кроме железа, будут влиять всяческие ограничения целостности, индексы, логгирование и т.д. Поэтому на целевой базе (той, куда пишем) отключить все что только можно - оставить голую таблицу. В общем случае, построить индексы позже - быстрее, чем делать это одновременно с миграцией данных. Ну и выгнать всех с сервера, естесвенно - конкуренция за диск тоже не нужна, понятное дело.
С чтением немного сложнее - тут очень зависит от конкретной базы и инструмента. Если работать средствами языка SQL (без всяких приблуд), то принцип примерно следующий:
Поскольку таблица большая, то запихнуть все одним куском не получится. Нужно читать таблицу кусками. Размер куска нужно подобрать, что может быть не совсем тривиальным. Например если куски слишком большие, то каждый из них будет провоцировать последовательное чтение таблицы. Соответсвенно, разбив миграцию на 10 больших шагов, ты последовательно просканируешь таблицу 10 раз. Это не есть эффективно.
Мне видится полезным разбить таблицу на более мелкие куски и сканировать их по индексу.